On Wed, Apr 13, 2016 at 5:42 AM, Wojciechowicz, RobertX <robertx.wojciechow...@intel.com> wrote: >> -----Original Message----- >> From: Jesse Gross [mailto:je...@kernel.org] >> Sent: Friday, March 25, 2016 7:57 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 >> >> The reason why some of the RSS modes you are enabling here aren't on >> by default is usually because they can introduce reordering. So I'm >> not really eager to go down this path unless you can show that there >> are specific reasons why the assumptions behind the default >> configuration don't apply here. >> > > To be honest I'm not sure how expanding rss hash may introduce reordering. > My understanding is that hash filter is a mechanism to statistically > distribute received > packets into several receive queues. By default there is used 5-tuple > (src_addr, > dst_addr, protocol, src_port, dst_port). This patch tries to expand > this tuple by mac or tunnel_id in order to reduce collisions for some traffic > flows > and improve packets distribution into queues. > Could you please explain why it may introduce reordering?
The set of RSS filters that you are enabling includes potentially fragmentable UDP packets. Typically these are not enabled in NICs by default as fragmented and non-fragmented frames will not go to the same queue since the former will not have L4 ports available for hashing. This can result in reordering. The overall point that I was trying to get at with my comments is that I would like you to understand and consider the problem that you are trying to solve more carefully. At the moment, I can't say that I have a lot of confidence that this will solve a real problem and not have undesired side effects. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
