[ovs-dev] [PATCH RFC] netdev-dpdk: Expand RSS hash calculation by MAC addresses

Wojciechowicz, RobertX robertx.wojciechowicz at intel.com
Fri Mar 25 14:45:58 UTC 2016


Hi Jesse,

please find my answers inline.

> -----Original Message-----
> From: Jesse Gross [mailto:jesse at kernel.org]
> Sent: Thursday, March 24, 2016 11:20 PM
> To: Wojciechowicz, RobertX <robertx.wojciechowicz at intel.com>
> Cc: ovs dev <dev at 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.wojciechowicz at 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.wojciechowicz at 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.


More information about the dev mailing list