From: Alexander Duyck <alexander.h.duyck@intel.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: "Kirsher, Jeffrey T" <jeffrey.t.kirsher@intel.com>,
"davem@davemloft.net" <davem@davemloft.net>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"gospo@redhat.com" <gospo@redhat.com>,
"bphilips@novell.com" <bphilips@novell.com>,
"Skidmore, Donald C" <donald.c.skidmore@intel.com>
Subject: Re: [net-next-2.6 PATCH 2/5] ixgbe: drop support for UDP in RSS hash generation
Date: Tue, 20 Jul 2010 09:11:50 -0700 [thread overview]
Message-ID: <4C45CAC6.1050006@intel.com> (raw)
In-Reply-To: <1279607980.2458.82.camel@edumazet-laptop>
Eric Dumazet wrote:
> Le lundi 19 juillet 2010 à 16:59 -0700, Jeff Kirsher a écrit :
>> From: Alexander Duyck <alexander.h.duyck@intel.com>
>>
>> This change removes UDP from the supported protocols for RSS hashing. The
>> reason for removing this protocol is because IP fragmentation was causing a
>> network flow to be broken into two streams, one for fragmented, and one for
>> non-fragmented and this in turn was causing out-of-order issues.
>>
>
> Jeff, does it mean all UDP packets are going to be delivered to a single
> queue ?
>
> This would be a serious regression.
>
> Many UDP applications try hard to not use fragments.
>
> They are going to pay the price because some application :
> - Use big segments, fragmented.
> - Is subject to OOO artifacts.
>
> We would like some clarifications please :)
>
>
>
The packets will still be hashed on source and destination IPv4/IPv6
addresses. The change just drops reading the UDP source/destination
ports since in the case of fragmented packets they are not available and
as such were being parsed as IPv4/IPv6 packets. By making this change
the queue selection is consistent between all packets in the UDP stream.
The only regression I would expect to see would be in testing between
two fixed systems since the IP addresses of the two systems would be
fixed and so running multiple flows between the two would yield the same
RSS hash for multiple UDP streams. As long as multiple ip addresses
are used you should see multiple RSS hashes generated and as such the
load should still be distributed.
Thanks,
Alex
next prev parent reply other threads:[~2010-07-20 16:12 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-19 23:59 [net-next-2.6 PATCH 1/5] ixgbe: dcb, set DPF bit when PFC is enabled Jeff Kirsher
2010-07-19 23:59 ` [net-next-2.6 PATCH 2/5] ixgbe: drop support for UDP in RSS hash generation Jeff Kirsher
2010-07-20 3:24 ` David Miller
2010-07-20 6:07 ` Bill Fink
2010-07-20 6:30 ` Eric Dumazet
2010-07-20 6:39 ` David Miller
2010-07-20 6:39 ` Eric Dumazet
2010-07-20 6:44 ` David Miller
2010-07-20 16:11 ` Alexander Duyck [this message]
2010-07-20 16:39 ` Eric Dumazet
2010-07-19 23:59 ` [net-next-2.6 PATCH 3/5] ixgbe: properly toggling netdev feature flags when disabling FCoE Jeff Kirsher
2010-07-20 3:24 ` David Miller
2010-07-20 0:00 ` [net-next-2.6 PATCH 4/5] ixgbe: use GFP_ATOMIC when allocating FCoE DDP context from the dma pool Jeff Kirsher
2010-07-20 3:24 ` David Miller
2010-07-20 0:00 ` [net-next-2.6 PATCH 5/5] ixgbe: fix version string for ixgbe Jeff Kirsher
2010-07-20 3:24 ` David Miller
2010-07-20 3:24 ` [net-next-2.6 PATCH 1/5] ixgbe: dcb, set DPF bit when PFC is enabled David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C45CAC6.1050006@intel.com \
--to=alexander.h.duyck@intel.com \
--cc=bphilips@novell.com \
--cc=davem@davemloft.net \
--cc=donald.c.skidmore@intel.com \
--cc=eric.dumazet@gmail.com \
--cc=gospo@redhat.com \
--cc=jeffrey.t.kirsher@intel.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.