From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 777703CB38 for ; Mon, 9 Oct 2017 17:04:39 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A9100E007; Mon, 9 Oct 2017 17:10:21 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 89A2181949; Mon, 9 Oct 2017 17:04:38 -0400 (EDT) From: Michael Richardson To: Dave Taht cc: bloat In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Subject: Re: [Bloat] emulating non-duplex media in linux qdiscs X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 21:04:39 -0000 --=-=-= Content-Type: text/plain Dave Taht 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 [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlnb5GYACgkQgItw+93Q 3WWUIAf9HC5uMhNBk1SyYa/KMkEhKxCnnWdqxXPbzTz7X9TRsY0KCXm/GJnnhWR+ pNSUXTSCr4upHVJCdYeaPfRG1Gtz8vJN78u162J83lyi+ERQ8Wwgen/LEdGQagDO aT5WYEuJ8QKxG4+cqhttYK3nkZMcXwVmozwNzUTp9V1ElXEJ9ZtBLafalkBLLFWw UCgwNNT+6S7gSWbEg707A2bMtft20wo5JJeP7MdiwRIcHIPDeFD0Pa8k6QlkUQWd nPhQ8pr60wIYiRMsbfUfKWezy9SUp61g9hiLSgzoNJnMgoRT51b0S/QYJyrrGMJN 08GTxPY/fRFltNMDJFVjOZdvVV8yGg== =Qiea -----END PGP SIGNATURE----- --=-=-=--