From: Alexander Duyck <alexander.h.duyck@intel•com>
To: Eric Dumazet <eric.dumazet@gmail•com>
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel•com>,
davem@davemloft•net, netdev@vger•kernel.org, gospo@redhat•com,
sassmann@redhat•com
Subject: Re: [net-next 09/14] igb: Report L4 Rx hash via skb->l4_rxhash
Date: Thu, 17 Jan 2013 09:23:10 -0800 [thread overview]
Message-ID: <50F8337E.9030302@intel.com> (raw)
In-Reply-To: <1358442889.29723.58.camel@edumazet-glaptop>
On 01/17/2013 09:14 AM, Eric Dumazet wrote:
> On Thu, 2013-01-17 at 09:07 -0800, Alexander Duyck wrote:
>
>> Isn't the same true of TCP? I believe STT is intended to run over the
>> TCP protocol, or am I getting ahead of myself since STT is not supported
>> by the kernel?
>>
>
> probably ;)
>
>>> Also, is IGB really using the ports in the rss for UDP packets ?
>>
>> Not by default. The default is to only hash on the IP header for UDP
>> packets.
>>
>> As such the default would only be setting the l4_rxhash on TCP frames
>> only. The user would have to specifically request L4 port hashing for
>> UDP via the "ethtool -N" command for configuring rx-flow-hash.
>
> So you should rewrite this patch ?
>
> Or have I missed something ?
I'm probably going to scrap it. No point in rewriting it.
I has assumed that there were other uses for the l4_rxhash value. If
all it is meant for is to indicate that the inner header of a tunnel was
used to compute the hash then there isn't much point to adding support
for this in igb/ixgbe since they don't support any inner header hashing.
It might add value at some point to rename the l4_rxhash flag to
something else though since it seems like there are now tunnels that are
encapsulated inside of l4 headers and it is going to get confusing.
Thanks,
Alex
next prev parent reply other threads:[~2013-01-17 17:23 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-17 11:35 [net-next 00/14][pull request] Intel Wired LAN Driver Updates Jeff Kirsher
2013-01-17 11:35 ` [net-next 01/14] e1000e: add ethtool .get_eee/.set_eee Jeff Kirsher
2013-01-17 11:35 ` [net-next 02/14] e1000e: Use standard #defines for PCIe Capability ASPM fields Jeff Kirsher
2013-01-17 11:35 ` [net-next 03/14] e1000e: add support for hardware timestamping on some devices Jeff Kirsher
2013-01-17 11:35 ` [net-next 04/14] e1000e: add support for IEEE-1588 PTP Jeff Kirsher
2013-01-17 15:35 ` Richard Cochran
2013-01-18 1:13 ` Allan, Bruce W
2013-01-17 15:56 ` Stephen Hemminger
2013-01-18 1:13 ` Allan, Bruce W
2013-01-18 6:27 ` Jeff Kirsher
2013-01-17 11:35 ` [net-next 05/14] igb: Enable SR-IOV configuration via PCI sysfs interface Jeff Kirsher
2013-01-17 11:35 ` [net-next 06/14] igb: Add i2c interface to igb Jeff Kirsher
2013-01-17 11:35 ` [net-next 07/14] igb: Add support functions to access thermal data Jeff Kirsher
2013-01-17 11:35 ` [net-next 08/14] igb: Enable hwmon data output for thermal sensors via I2C Jeff Kirsher
2013-01-17 11:35 ` [net-next 09/14] igb: Report L4 Rx hash via skb->l4_rxhash Jeff Kirsher
2013-01-17 14:19 ` Eric Dumazet
2013-01-17 17:07 ` Alexander Duyck
2013-01-17 17:14 ` Eric Dumazet
2013-01-17 17:23 ` Alexander Duyck [this message]
2013-01-17 18:46 ` Jesse Gross
2013-01-17 11:35 ` [net-next 10/14] igb: Add support for SW timestamping Jeff Kirsher
2013-01-17 11:35 ` [net-next 11/14] igb: Add timeout for PTP Tx work item Jeff Kirsher
2013-01-17 11:35 ` [net-next 12/14] igb: Add mechanism for detecting latched hardware Rx timestamp Jeff Kirsher
2013-01-17 15:38 ` Richard Cochran
2013-01-17 16:51 ` Vick, Matthew
2013-01-17 11:35 ` [net-next 13/14] igb: Use in-kernel PTP_EV_PORT #define Jeff Kirsher
2013-01-17 11:35 ` [net-next 14/14] igb: Free any held skb that should have been timestamped on remove Jeff Kirsher
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=50F8337E.9030302@intel.com \
--to=alexander.h.duyck@intel$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=eric.dumazet@gmail$(echo .)com \
--cc=gospo@redhat$(echo .)com \
--cc=jeffrey.t.kirsher@intel$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=sassmann@redhat$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox