Re: [Bloat] emulating non-duplex media in linux qdiscs

[Michael Richardson <mcr@sandelman.ca>]

[-- Attachment #1: Type: text/plain, Size: 1682 bytes --]


Dave Taht <dave.taht@gmail.com> wrote:
    > (Some people try to describe these as simplex (which is not true
    > because you can have multiple destinations), and they certainly are
    > not duplex, so I tend to say non-duplex and still hope some better
    > word emerges)

semi-multiplex?

    > So... one sticking point for me has been wanting to emulate the fact
    > that on shared media, that you cannot transmit and receive at the same
    > time; that these are "coupled" events, and what I'd like to be able to
    > express might be something like:

    > tc qdisc add dev eth0 root netem rate 100mbit coupled some_identifier
    > ... some tc mirred magic for ifb here ...
    > tc qdisc add dev ifb0 root netem rate 10mbit coupled the_same_identifier

    > "some_identifier" would be a mutex of some sort, and I confess to
    > not having much grip on the kernel outside of the net/sched directory.

    > What facility would be best to try and leverage? It would be created
    > (globally) on first use, ref-counted (thus destroyed when it goes to
    > zero), atomically updated... posix shared memory seems too heavyweight
    > to use....

I suspect (being equally ignorant of kernel stuff in the last decade) that
anytime you create a mutex that needs to be consistent across CPUs, that you
have to put it on a seperate page so that it can be flushed appropriately, so
I suspect that the overhead is already there.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]