Flow ID, LACP, and igb

[Andre Oppermann]

On 26.08.2013 19:18, Justin T. Gibbs wrote:
> Hi Net,
>
> I'm an infrequent traveler through the networking code and would
> appreciate some feedback on some proposed solutions to issues Spectra
> has seen with outbound LACP traffic.
>
> lacp_select_tx_port() uses the flow ID if it is available in the outbound
> mbuf to select the outbound port.  The igb driver uses the msix queue of
> the inbound packet to set a packet's flow ID.  This doesn't provide enough
> bits of information to yield a high quality flow ID.  If, for example, the
> switch controlling inbound packet distribution does a poor job, the outbound
> packet distribution will also be poorly distributed.

Please note that inbound and outbound flow ID do not need to be the same
or symmetric.  It only should stay the same for all packets in a single
connection to prevent reordering.

Generally it doesn't matter if in- and outbound packets do not use the
same queue.  Only in sophisticated setups with full affinity, which we
don't support yet, it could matter.

> The majority of the adapters supported by this driver will compute
> the Toeplitz RSS hash.  Using this data seems to work quite well
> in our tests (3 member LAGG group).  Is there any reason we shouldn't
> use the RSS hash for flow ID?

Using the RSS hash is the idea.  The infrastructure and driver adjustments
haven't been implemented throughout yet.

> We also tried disabling the use of flow ID and doing the hash directly in
> the driver.  Unfortunately, the current hash is pretty weak.  It multiplies
> by 33, which yield very poor distributions if you need to mod the result
> by 3 (e.g. LAGG group with 3 members).  Alan modified the driver to use
> the FNV hash, which is already in the kernel, and this yielded much better
> results.  He is still benchmarking the impact of this change.  Assuming we
> can get decent flow ID data, this should only impact outbound UDP, since the
> stack doesn't provide a flow ID in this case.
>
> Are there other checksums we should be looking at in addition to FNV?

siphash24() is fast, keyed and strong.

-- 
Andre