HI Adrien,
Thank you for your effort and considering the inputs and comments.
The design looks fine for me now.


Regards
_Sugesh

-----Original Message-----
From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
Sent: Thursday, July 21, 2016 2:37 PM
To: Chandran, Sugesh <redacted>
Cc: dev@dpdk.org; Thomas Monjalon <redacted>;
Zhang, Helin [off-list ref]; Wu, Jingjing
[off-list ref]; Rasesh Mody [off-list ref]; Ajit
Khaparde [off-list ref]; Rahul Lakkireddy
[off-list ref]; Lu, Wenzhuo [off-list ref];
Jan Medala [off-list ref]; John Daley [off-list ref]; Chen,
Jing D [off-list ref]; Ananyev, Konstantin
[off-list ref]; Matej Vido [off-list ref];
Alejandro Lucero [off-list ref]; Sony Chacko
[off-list ref]; Jerin Jacob
[off-list ref]; De Lara Guarch, Pablo
[off-list ref]; Olga Shern [off-list ref];
Chilikin, Andrey [off-list ref]
Subject: Re: [dpdk-dev] [RFC] Generic flow director/filtering/classification
API

Hi Sugesh,

I do not have much to add, please see below.

On Thu, Jul 21, 2016 at 11:06:52AM +0000, Chandran, Sugesh wrote:
[...]

quoted

quoted

quoted

RSS hashing support :- Just to confirm, the RSS flow action allows
application to decide the header fields to produce the hash. This
gives programmability on load sharing across different queues. The
application can program the NIC to calculate the RSS hash only
using mac or mac+ ip or ip only using this.

I'd say yes but from your summary, I'm not sure we share the same
idea of what the RSS action is supposed to do, so here is mine.

Like all flow rules, the pattern part of the RSS action only filters
the packets on which the action will be performed.

The rss_conf parameter (struct rte_eth_rss_conf) only provides a key
and a RSS hash function to use (ETH_RSS_IPV4,
ETH_RSS_NONFRAG_IPV6_UDP, etc).

Nothing prevents the RSS hash function from being applied to
protocol headers which are not necessarily present in the flow rule
pattern. These are two independent things, e.g. you could have a
pattern matching IPv4 packets yet perform RSS hashing only on UDP

headers.

quoted

quoted

Finally, the RSS action configuration only affects packets coming
from this flow rule. It is not performed on the device globally so
packets which are not matched are not affected by RSS processing. As
a result it might not be possible to configure two flow rules
specifying incompatible RSS actions simultaneously if the underlying
device supports only a single global RSS context.

[Sugesh] thank you for the explanation. This means I can have a rule
that matches on Every incoming packets(all field wild card rule) and
does RSS hash on selected fields, MAC only, IP only or IP & MAC?

Yes, I guess it could even replace the current method for configuring RSS on a
device in a more versatile fashion, but this is a topic for another debate.

Let's implement this API first!

quoted

This can be useful to do a packet lookup in software by just using
Only hash.

Not sure to fully understand your idea, but I'm positive it could be done
somehow :)

--
Adrien Mazarguil
6WIND