Hi Jesse, please find my answers inline.
> -----Original Message----- > From: Jesse Gross [mailto:je...@kernel.org] > Sent: Thursday, March 24, 2016 11:20 PM > To: Wojciechowicz, RobertX <robertx.wojciechow...@intel.com> > Cc: ovs dev <dev@openvswitch.org> > Subject: Re: [ovs-dev] [PATCH RFC] netdev-dpdk: Expand RSS hash > calculation by MAC addresses > > On Thu, Mar 24, 2016 at 7:30 AM, Robert Wojciechowicz > <robertx.wojciechow...@intel.com> wrote: > > This patch configures RSS hash filter in DPDK in order to include > > source and destination MAC addresses into RSS hash calculation. > > This configuration considerably improves performance for flows > > with overlapping IP address spaces and non-overlapping Ethernet > > address spaces. > > Here is the example test result (throughput in frames per second) > > I have done for 16 flows (fixed IP addresses and changing source > > MAC addresses) on X710 for 10GbE SFP+: > > > > 1. original hash calculation: 4870667 fps > > 2. expanded hash calculation (with this patch): 12740258 fps > > > > Signed-off-by: Robert Wojciechowicz <robertx.wojciechow...@intel.com> > > This is somewhat of an unusual configuration - I guess as evidenced by > the fact that it is not supported by ixgbe. > > How much of a difference does this make in non-synthetic benchmarks? I > would expect in most cases that the use of L4 ports would provide > sufficient entropy even in cases where there are overlapping IP > addresses. > In most cases you're probably right, but there are use cases where this overlapping exists. For example in openstack configurations with many tenants. The idea of this patch is to make this configuration possible for people who really need it. > Two other concerns: > * This appears to enable hashing for a wide range of packets, > including IP fragments, which would typically allow the possibility of > reordering. I think we probably want to be a little more careful in > considering what to include. > * I think we need to more gracefully handle NICs where this > configuration is not supported. I don't like that we should what looks > like an error message in normal conditions. Unfortunately DPDK returns EINVAL error also for unsupported operations, so I couldn't handle it in more reasonable way. I wanted to make it minimally invasive for other hardware than XL710, so I report all errors as info messages. Basically I'm not sure if there is some recommended approach for providing functionality to OVS, which is hardware specific? If there is any I could of course reimplement this patch appropriately. Br, Robert -------------------------------------------------------------- Intel Research and Development Ireland Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev