public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Jiri Pirko <jiri@resnulli.us>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: Pablo Neira Ayuso <pablo@netfilter.org>,
	netdev@vger.kernel.org, davem@davemloft.net,
	thomas.lendacky@amd.com, ariel.elior@cavium.com,
	michael.chan@broadcom.com, santosh@chelsio.com,
	madalin.bucur@nxp.com, yisen.zhuang@huawei.com,
	salil.mehta@huawei.com, jeffrey.t.kirsher@intel.com,
	tariqt@mellanox.com, saeedm@mellanox.com, jiri@mellanox.com,
	idosch@mellanox.com, jakub.kicinski@netronome.com,
	peppe.cavallaro@st.com, grygorii.strashko@ti.com, andrew@lunn.ch,
	vivien.didelot@savoirfairelinux.com, alexandre.torgue@st.com,
	joabreu@synopsys.com, linux-net-drivers@solarflare.com,
	ganeshgr@chelsio.com, ogerlitz@mellanox.com,
	Manish.Chopra@cavium.com
Subject: Re: [PATCH net-next,v3 09/12] flow_dissector: add basic ethtool_rx_flow_spec to flow_rule structure translator
Date: Thu, 22 Nov 2018 07:19:52 +0100	[thread overview]
Message-ID: <20181122061952.GI2264@nanopsycho> (raw)
In-Reply-To: <191049db-be77-811b-1c6d-59c5c9a2d251@gmail.com>

Thu, Nov 22, 2018 at 05:57:31AM CET, f.fainelli@gmail.com wrote:
>
>
>On 11/20/2018 6:51 PM, Pablo Neira Ayuso wrote:
>> This patch adds a function to translate the ethtool_rx_flow_spec
>> structure to the flow_rule representation.
>> 
>> This allows us to reuse code from the driver side given that both flower
>> and ethtool_rx_flow interfaces use the same representation.
>> 
>> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
>> ---
>> v3: Suggested by Jiri Pirko:
>>         - Add struct ethtool_rx_flow_rule, keep placeholder to private
>>           dissector information.
>>     Reported by Manish Chopra:
>> 	- Fix incorrect dissector user_keys flags.
>> 
>>  include/linux/ethtool.h |  10 +++
>>  net/core/ethtool.c      | 189 ++++++++++++++++++++++++++++++++++++++++++++++++
>>  2 files changed, 199 insertions(+)
>> 
>> diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
>> index afd9596ce636..99849e0858b2 100644
>> --- a/include/linux/ethtool.h
>> +++ b/include/linux/ethtool.h
>> @@ -400,4 +400,14 @@ struct ethtool_ops {
>>  	void	(*get_ethtool_phy_stats)(struct net_device *,
>>  					 struct ethtool_stats *, u64 *);
>>  };
>> +
>> +struct ethtool_rx_flow_rule {
>> +	struct flow_rule	*rule;
>> +	unsigned long		priv[0];
>> +};
>> +
>> +struct ethtool_rx_flow_rule *
>> +ethtool_rx_flow_rule_alloc(const struct ethtool_rx_flow_spec *fs);
>> +void ethtool_rx_flow_rule_free(struct ethtool_rx_flow_rule *rule);
>> +
>>  #endif /* _LINUX_ETHTOOL_H */
>> diff --git a/net/core/ethtool.c b/net/core/ethtool.c
>> index d05402868575..e679d6478371 100644
>> --- a/net/core/ethtool.c
>> +++ b/net/core/ethtool.c
>> @@ -28,6 +28,7 @@
>>  #include <linux/sched/signal.h>
>>  #include <linux/net.h>
>>  #include <net/xdp_sock.h>
>> +#include <net/flow_offload.h>
>>  
>>  /*
>>   * Some useful ethtool_ops methods that're device independent.
>> @@ -2808,3 +2809,191 @@ int dev_ethtool(struct net *net, struct ifreq *ifr)
>>  
>>  	return rc;
>>  }
>> +
>> +struct ethtool_rx_flow_key {
>> +	struct flow_dissector_key_basic			basic;
>> +	union {
>> +		struct flow_dissector_key_ipv4_addrs	ipv4;
>> +		struct flow_dissector_key_ipv6_addrs	ipv6;
>> +	};
>> +	struct flow_dissector_key_ports			tp;
>> +	struct flow_dissector_key_ip			ip;
>> +} __aligned(BITS_PER_LONG / 8); /* Ensure that we can do comparisons as longs. */
>> +
>> +struct ethtool_rx_flow_match {
>> +	struct flow_dissector		dissector;
>> +	struct ethtool_rx_flow_key	key;
>> +	struct ethtool_rx_flow_key	mask;
>> +};
>> +
>> +struct ethtool_rx_flow_rule *
>> +ethtool_rx_flow_rule_alloc(const struct ethtool_rx_flow_spec *fs)
>
>This is more than alloc, it's allocate and map, no reason to split the
>two operations AFAICT, but the name could be improved, how about
>alloc_from()?

Or ethtool_rx_flow_rule_create() and ethtool_rx_flow_rule_destroy()


>
>> +{
>> +	static struct in6_addr zero_addr = {};
>> +	struct ethtool_rx_flow_match *match;
>> +	struct ethtool_rx_flow_rule *flow;
>> +	struct flow_action_entry *act;
>> +
>> +	flow = kzalloc(sizeof(struct ethtool_rx_flow_rule) +
>> +		       sizeof(struct ethtool_rx_flow_match), GFP_KERNEL);
>> +	if (!flow)
>> +		return NULL;
>> +
>> +	/* ethtool_rx supports only one single action per rule. */
>> +	flow->rule = flow_rule_alloc(1);
>> +	if (!flow->rule) {
>> +		kfree(flow);
>> +		return NULL;
>> +	}
>> +
>> +	match = (struct ethtool_rx_flow_match *)flow->priv;
>> +	flow->rule->match.dissector	= &match->dissector;
>> +	flow->rule->match.mask		= &match->mask;
>> +	flow->rule->match.key		= &match->key;
>> +
>> +	match->mask.basic.n_proto = 0xffff;
>> +
>> +	switch (fs->flow_type & ~FLOW_EXT) {
>> +	case TCP_V4_FLOW:
>> +	case UDP_V4_FLOW: {
>> +		const struct ethtool_tcpip4_spec *v4_spec, *v4_m_spec;
>> +
>> +		match->key.basic.n_proto = htons(ETH_P_IP);
>> +
>> +		v4_spec = &fs->h_u.tcp_ip4_spec;
>> +		v4_m_spec = &fs->m_u.tcp_ip4_spec;
>> +
>> +		if (v4_m_spec->ip4src) {
>> +			match->key.ipv4.src = v4_spec->ip4src;
>> +			match->mask.ipv4.src = v4_m_spec->ip4src;
>> +		}
>> +		if (v4_m_spec->ip4dst) {
>> +			match->key.ipv4.dst = v4_spec->ip4dst;
>> +			match->mask.ipv4.dst = v4_m_spec->ip4dst;
>> +		}
>
>I got confused a while ago between the ethtool ntuple and nfc semantics,
>and I can't remember if the following is true:
>
>- bits set to 1 indicate a match and bit set to 0 indicate a don't care
>for nfc
>- bits set to 0 indicate a match and bit set to 1 indicate a don't care
>for ntuple
>
>Depending on the answer that could mean that this check on a zero
>address may have to change.
>
>> +		if (v4_m_spec->ip4src ||
>> +		    v4_m_spec->ip4dst) {
>> +			match->dissector.used_keys |=
>> +				(1 << FLOW_DISSECTOR_KEY_IPV4_ADDRS);
>
>Can you use BIT() here (and likewise for every one below).
>
>[snip]
>> +
>> +	return flow;
>
>What about the extended fields and non-IP protocols?
>-- 
>Florian

  reply	other threads:[~2018-11-22 17:04 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-21  2:51 [PATCH net-next,v3 00/12] add flow_rule infrastructure Pablo Neira Ayuso
2018-11-21  2:51 ` [PATCH net-next,v3 01/12] flow_dissector: add flow_rule and flow_match structures and use them Pablo Neira Ayuso
2018-11-21  2:51 ` [PATCH net-next,v3 02/12] net/mlx5e: support for two independent packet edit actions Pablo Neira Ayuso
2018-11-21  2:51 ` [PATCH net-next,v3 03/12] flow_dissector: add flow action infrastructure Pablo Neira Ayuso
2018-11-22  4:47   ` Florian Fainelli
2018-11-21  2:51 ` [PATCH net-next,v3 04/12] cls_api: add translator to flow_action representation Pablo Neira Ayuso
2018-11-21 21:15   ` Marcelo Ricardo Leitner
2018-11-21 23:48     ` Pablo Neira Ayuso
2018-11-22 16:33   ` Marcelo Ricardo Leitner
2018-11-21  2:51 ` [PATCH net-next,v3 05/12] cls_flower: add statistics retrieval infrastructure and use it Pablo Neira Ayuso
2018-11-21  2:51 ` [PATCH net-next,v3 06/12] drivers: net: use flow action infrastructure Pablo Neira Ayuso
2018-11-21  2:51 ` [PATCH net-next,v3 07/12] cls_flower: don't expose TC actions to drivers anymore Pablo Neira Ayuso
2018-11-21  2:51 ` [PATCH net-next,v3 08/12] flow_dissector: add wake-up-on-lan and queue to flow_action Pablo Neira Ayuso
2018-11-21  2:51 ` [PATCH net-next,v3 09/12] flow_dissector: add basic ethtool_rx_flow_spec to flow_rule structure translator Pablo Neira Ayuso
2018-11-22  4:57   ` Florian Fainelli
2018-11-22  6:19     ` Jiri Pirko [this message]
2018-11-22  4:59   ` Florian Fainelli
2018-11-22  6:21     ` Jiri Pirko
2018-11-21  2:51 ` [PATCH net-next,v3 10/12] dsa: bcm_sf2: use flow_rule infrastructure Pablo Neira Ayuso
2018-11-22  4:56   ` Florian Fainelli
2018-11-21  2:51 ` [PATCH net-next,v3 11/12] qede: place ethtool_rx_flow_spec after code after TC flower codebase Pablo Neira Ayuso
2018-11-21  2:51 ` [PATCH net-next,v3 12/12] qede: use ethtool_rx_flow_rule() to remove duplicated parser code Pablo Neira Ayuso
2018-11-22 16:59   ` Marcelo Ricardo Leitner
2018-11-22 16:22 ` [PATCH net-next,v3 00/12] add flow_rule infrastructure Marcelo Ricardo Leitner
2018-11-22 21:08   ` Marcelo Ricardo Leitner
2018-11-26 19:33     ` Pablo Neira Ayuso
2018-11-26 20:28       ` Marcelo Ricardo Leitner

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=20181122061952.GI2264@nanopsycho \
    --to=jiri@resnulli.us \
    --cc=Manish.Chopra@cavium.com \
    --cc=alexandre.torgue@st.com \
    --cc=andrew@lunn.ch \
    --cc=ariel.elior@cavium.com \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=ganeshgr@chelsio.com \
    --cc=grygorii.strashko@ti.com \
    --cc=idosch@mellanox.com \
    --cc=jakub.kicinski@netronome.com \
    --cc=jeffrey.t.kirsher@intel.com \
    --cc=jiri@mellanox.com \
    --cc=joabreu@synopsys.com \
    --cc=linux-net-drivers@solarflare.com \
    --cc=madalin.bucur@nxp.com \
    --cc=michael.chan@broadcom.com \
    --cc=netdev@vger.kernel.org \
    --cc=ogerlitz@mellanox.com \
    --cc=pablo@netfilter.org \
    --cc=peppe.cavallaro@st.com \
    --cc=saeedm@mellanox.com \
    --cc=salil.mehta@huawei.com \
    --cc=santosh@chelsio.com \
    --cc=tariqt@mellanox.com \
    --cc=thomas.lendacky@amd.com \
    --cc=vivien.didelot@savoirfairelinux.com \
    --cc=yisen.zhuang@huawei.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox