From: Ben Hutchings <bhutchings@solarflare•com>
To: Vladislav Zolotarov <vladz@broadcom•com>
Cc: Dimitris Michailidis <dm@chelsio•com>,
Peter Waskiewicz <peter.p.waskiewicz.jr@intel•com>,
"netdev@vger•kernel.org" <netdev@vger•kernel.org>,
David Miller <davem@davemloft•net>
Subject: Re: (Lack of) specification for RX n-tuple filtering
Date: Wed, 08 Dec 2010 17:22:20 +0000 [thread overview]
Message-ID: <1291828940.2560.17.camel@bwh-desktop> (raw)
In-Reply-To: <1291825443.31064.193.camel@lb-tlvb-vladz>
On Wed, 2010-12-08 at 18:24 +0200, Vladislav Zolotarov wrote:
> > > It's a bit worse than that. Currently one can only append filters, not
> > > insert at a given position, as ethtool_rx_ntuple doesn't have an index
> > > field. For devices that use TCAMs, where position matters, it's quite an
> > > obstacle. It also means one cannot modify an existing filter by specifying
> > > a new filter for the same index.
> >
> > It looks like drivers for devices that use TCAMs should implement the
> > RXNFC interface instead.
> >
>
> Ben, from ethtool manpage it sounds like RXNFC option defines the way
> the RSS hash should be calculated, while SRXNTUPLE is meant to control
> the destination Rx queue for a stream specified by a filter/filters.
By 'RXNFC interface' I mean ETHTOOL_{G,S}RXCLS* and not
ETHTOOL_{G,S}RXFH which wrongly share (part of) the same structure..
> The
> semantics for a specification of the steam is also quite different. For
> instance, how do u define a rule to drop all packets with source IP
> address 192.168.10.200 by means of RXNFC?
Something like this, I think:
struct ethtool_rxnfc insert_rule = {
.cmd = ETHTOOL_SRXCLSRLINS,
.flow_type = IP_USER_SPEC,
.fs = {
.flow_type = IP_USER_SPEC,
.h_u.usr_ip4_spec = {
.ip4src = inet_aton("192.168.10.200"),
.ip_ver = ETH_RX_NFC_IP4
},
.m_u.usr_ip4_spec = {
.ip4dst = 0xffffffff,
.l4_4_bytes = 0xffffffff,
.tos = 0xff,
.proto = 0xff
},
.ring_cookie = RX_CLS_FLOW_DISC,
.location = 0,
}
};
[...]
> I also agree with Dimitris: what we have here is an offload of some
> Netfilter functionality to HW. Regardless the HW implementation (TCAM or
> not) if it's allowed to configure more than one rule for the same
> protocol the ordering of filtering rules is important: for instance if u
> change the order of applying the rules in the example below the result
> of the filtering for the traffic with both VLAN 4 and destination port
> 3000 will be different.
Our hardware (and, I suspect, the ixgbe hardware) has hash tables for
specific types of matching. There is some control of precedence between
different types of match, but that's all.
> ethtool -U ethX flow-type tcp4 vlan 4 action 0
> ethtool -U ethX flow-type tcp4 dst-port 3000 action 3
>
> By the way it's also unclear from the ethtool man page if it's allowed
> to configure more than one rule for the same protocol. If it's not then
> the above example is void... ;)
It's allowed, but precedence is unspecified.
> However, if we want to define a proper
> filtering interface I think we shouldn't restrict the driver
> implementation from defining a set of rules for the same protocol,
> allowing not to though.
>
> So, I think that attaching an index to each rule could be a good idea -
> this would allow us both inserting rules at the desired positions in the
> filtering rule table and editing the existing rules.
This really sounds like the RXNFC interface.
> It's also unclear what is the relation between RXNFC and SRXNTUPLE. The
> last in general may override the decision made based on the hash result.
> So, it sounds like applying rules of SRXNTUPLE should come before
> applying the RSS logic and only if there was no match RSS should be
> applied to that frame. Do I get it right?
That's right.
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.
next prev parent reply other threads:[~2010-12-08 17:22 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-22 21:02 (Lack of) specification for RX n-tuple filtering Ben Hutchings
2010-07-22 21:50 ` Dimitris Michailidis
2010-09-07 14:43 ` Ben Hutchings
2010-12-08 16:24 ` Vladislav Zolotarov
2010-12-08 16:39 ` David Miller
2010-12-08 17:29 ` Ben Hutchings
2010-12-08 17:31 ` David Miller
2010-12-09 10:31 ` Vladislav Zolotarov
2010-12-08 17:31 ` Vladislav Zolotarov
2010-12-08 17:22 ` Ben Hutchings [this message]
2010-12-08 18:39 ` Vladislav Zolotarov
2010-12-08 19:02 ` Ben Hutchings
2010-12-08 19:10 ` Vladislav Zolotarov
2010-12-08 19:14 ` Ben Hutchings
2010-12-08 19:39 ` Ben Hutchings
2010-12-08 18:54 ` Dimitris Michailidis
2010-12-08 19:14 ` Ben Hutchings
2010-12-08 19:26 ` Dimitris Michailidis
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=1291828940.2560.17.camel@bwh-desktop \
--to=bhutchings@solarflare$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=dm@chelsio$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=peter.p.waskiewicz.jr@intel$(echo .)com \
--cc=vladz@broadcom$(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