netdev - Re: [PATCH] remove claim balance_rr won't reorder on many to one

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 30 Oct 2007 18:02:05 -0700
From:	Rick Jones <rick.jones2@...com>
To:	Jay Vosburgh <fubar@...ibm.com>
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH] remove claim balance_rr won't reorder on many to one

Jay Vosburgh wrote:
> Rick Jones <rick.jones2@...com> wrote:
> 
> 
>>I have to wonder if the full description of the different versions of
>>being a little bit pregnant is worth it.  Just saying that using
>>balance-rr will result in reordering seems much more simple to comprehend.
> 
> 
> 	True, but the different configurations produce very different
> levels of reordering.
> 
> 	There seem to be users out there trying to use balance-rr to
> maximize single stream TCP throughput (even with reordering), so I think
> the relative badness information is worthwhile.

I will admit to coming from an "if you want a single stream to go faster buy the 
next higher speed NIC" point of view, which means I pretty much lump all the 
degrees of reordering badness together.

The relative badness though is likely a _very_ broad space which couldn't be 
covered adequately in just a paragraph or two.  Notice how long my email 
describing my one experiment ended-up.

For example, I suspect, but have not verified that the one way one might get 
minimal reordering with many to one would be to have a sender with the many 
interfaces slow enough to not be able to get ahead of the sum of the NICs in the 
bond, so the transmit queues all remain at 0, coupled perhaps with NICs all in 
equal-speed and equal-feed I/O slots.

Start to be able to keep ahead of one or more of the NICs and soon we are 
starting along a rather long continuum which includes whether there are other 
concurrent connections, the distribution of send() sized by the applications, 
whether or not various offloads are enabled etc etc etc...

>>Also, since balance-rr is strictly an outbound policy, does case three
>>even enter into it - as you say, that will be up to the switch, which will
>>be doing whatever it was told or felt like doing regardless of balance-rr
>>on the bond in the host.
> 
> 
> 	Point three provides an answer to a question I've been asked
> pretty regularly by customers, so I think it's good information.

But since it isn't specific to balance_rr it would seem better placed in a 
"Switch Considerations" or "Inbound Considerations" section?

>>Even better would be to be able to start to move away from "etherchannel"
>>towards the de jure standard's terms, whatever the heck they are :)
> 
> 
> 	I believe that EtherChannel is the standard term for what we're
> talking about here, but it's a Cisco trademark.  I'd guess that most
> switch vendors don't come right out and call their "EtherChannel(tm)
> compatible" mode exactly that; they call it something else, but it's
> still meant to be compatible with EtherChannel.

Well, that assumes that many switch vendors are still including EtherChannel.  I 
know of at least one non-trivial switch vendor which has consolidated on 
LACP/802.3ad.  When that vendor was supporting EtherChannel, they called it such.

rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html