[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4A6A2125329CFD4D8CC40C9E8ABCAB9F249E3CEB8A@MILEXCH2.ds.jdsu.net>
Date: Mon, 24 Jan 2011 23:22:31 -0800
From: Jon Zhou <Jon.Zhou@...u.com>
To: Ben Hutchings <bhutchings@...arflare.com>,
Rui <wirelesser@...il.com>
CC: Alexander Duyck <alexander.h.duyck@...el.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"e1000-devel@...ts.sourceforge.net"
<e1000-devel@...ts.sourceforge.net>
Subject: RE: does intel X520-SR(ixgbe) support RSS on single VLAN?
> -----Original Message-----
> From: Ben Hutchings [mailto:bhutchings@...arflare.com]
> Sent: Tuesday, January 25, 2011 11:06 AM
> To: Rui
> Cc: Alexander Duyck; netdev@...r.kernel.org; e1000-
> devel@...ts.sourceforge.net
> Subject: Re: does intel X520-SR(ixgbe) support RSS on single VLAN?
>
> On Tue, 2011-01-25 at 10:10 +0800, Rui wrote:
> > On Tue, Jan 25, 2011 at 1:09 AM, Alexander Duyck
> > <alexander.h.duyck@...el.com> wrote:
> > > On 1/24/2011 6:18 AM, Rui wrote:
> > >>
> > >> hi
> > >> does intel X520-SR support RSS on single VLAN?
> > >>
> > >> tested with 3 different vlan id and priority packets
> > >> What I saw is that all packets were always delivered to the same
> RxQ.
> > >> looks can not get a different RSS index for these packet?
> > >> any setting needed?
> > >> --
> > >> To unsubscribe from this list: send the line "unsubscribe netdev"
> in
> > >> the body of a message to majordomo@...r.kernel.org
> > >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> > >
> > > The X520 should have no problems hashing on a single VLAN tagged
> frame.
> > > However the VLAN will not be a part of the RSS hash. The only
> components
> > > of the hash are the IPv4/IPv6 source and destination addresses, and
> if the
> > > flow is TCP then the port numbers.
> > >
> > hi alexander
> > I got these information from the intel community:
> >
> > 'I asked our software engineers about your question, and this is what
> I learned.
> > You cannot filter by just VLAN or VLAN priority. The L4 type will
> > also play a role in the filter and as such you would only be able to
> > filter TCP, UDP, and SCTP packets that are bound for a VLAN.
> > The command itself to setup a filter is “ethtool –U ethX flow-type
> > tcp4 vlan 0x2000 vlan-mask 0xE000 action Y” where X is the correct
> > index for the interface and Y is the queue you want to route the
> > traffic to. This would have to be repeated for udp4 and sctp4.
> > I hope this will help.
> > Mark H"
>
> The mask specifies bits to be ignored, so if you want to filter on the
> basis of only the priority bits you should use vlan-mask 0xfff. Unless
> this is another inconsistency I failed to notice...
>
> > so my question is that the VLAN is PART of the RSS or not?
>
> It's not part of any specified Toeplitz hash. However, some hardware
> supports adding the hash (after indirection) to the queue number
> specified by a filter. Currently the ethtool API doesn't have a way to
> request that.
>
> > looks the
> > perfect filter support vlan id ?can the perfect filter support
> > wildchar,such as: flow-type ANY?
>
> It is possible to specify this using flow-type ether, but the ixgbe
> driver does not yet support that (and I have no idea whether the
> hardware does).
>
ethtool –U ethX flow-type tcp4 vlan 0x2000 vlan-mask 0xE000 action Y”
I got this msg:
Cannot add new RX n-tuple filter: Operation not supported
This command is only supported after 2.6.24?
Quoted:
"ethtool: Introduce n-tuple filter programming support
author Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@...el.com>
Thu, 11 Feb 2010 04:03:05 +0000 (20:03 -0800)
committer David S. Miller <davem@...emloft.net>
Thu, 11 Feb 2010 04:03:05 +0000 (20:03 -0800)
This patchset enables the ethtool layer to program n-tuple
filters to an underlying device. The idea is to allow capable
hardware to have static rules applied that can assist steering
flows into appropriate queues.
Hardware that is known to support these types of filters today
are ixgbe and niu.
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@...el.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@...el.com>
Signed-off-by: David S. Miller <davem@...emloft.net>
"
> Ben.
>
> --
> Ben Hutchings, Senior Software Engineer, Solarflare Communications
> Not speaking for my employer; that's the marketing department's job.
> They asked us to note that Solarflare product names are trademarked.
Powered by blists - more mailing lists