From: Florian Fainelli <f.fainelli@gmail.com>
To: Alexander Lobakin <alobakin@dlink.ru>,
"David S. Miller" <davem@davemloft.net>
Cc: Andrew Lunn <andrew@lunn.ch>, Song Liu <songliubraving@fb.com>,
Jakub Kicinski <jakub.kicinski@netronome.com>,
Yoshiki Komachi <komachi.yoshiki@gmail.com>,
linux-kernel@vger.kernel.org, Eric Dumazet <edumazet@google.com>,
Stanislav Fomichev <sdf@google.com>,
Matteo Croce <mcroce@redhat.com>,
Edward Cree <ecree@solarflare.com>,
Jakub Sitnicki <jakub@cloudflare.com>,
Daniel Borkmann <daniel@iogearbox.net>,
Paolo Abeni <pabeni@redhat.com>,
Vivien Didelot <vivien.didelot@gmail.com>,
Hauke Mehrtens <hauke@hauke-m.de>,
Sean Wang <sean.wang@mediatek.com>,
Jiri Pirko <jiri@mellanox.com>,
linux-mediatek@lists.infradead.org,
Matthias Brugger <matthias.bgg@gmail.com>,
linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org,
Paul Blakey <paulb@mellanox.com>,
Stephen Hemminger <stephen@networkplumber.org>,
Taehee Yoo <ap420073@gmail.com>
Subject: Re: [PATCH RFC net-next 05/19] net: dsa: tag_ar9331: add GRO callbacks
Date: Mon, 30 Dec 2019 10:20:50 -0800 [thread overview]
Message-ID: <ee6f83fd-edf4-5a98-9868-4cbe9e226b9b@gmail.com> (raw)
In-Reply-To: <20191230143028.27313-6-alobakin@dlink.ru>
On 12/30/19 6:30 AM, Alexander Lobakin wrote:
> Add GRO callbacks to the AR9331 tagger so GRO layer can now process
> such frames.
>
> Signed-off-by: Alexander Lobakin <alobakin@dlink.ru>
This is a good example and we should probably build a tagger abstraction
that is much simpler to fill in callbacks for (although indirect
function calls may end-up killing performance with retpoline and
friends), but let's consider this idea.
> ---
> net/dsa/tag_ar9331.c | 77 ++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 77 insertions(+)
>
> diff --git a/net/dsa/tag_ar9331.c b/net/dsa/tag_ar9331.c
> index c22c1b515e02..99cc7fd92d8e 100644
> --- a/net/dsa/tag_ar9331.c
> +++ b/net/dsa/tag_ar9331.c
> @@ -100,12 +100,89 @@ static void ar9331_tag_flow_dissect(const struct sk_buff *skb, __be16 *proto,
> *proto = ar9331_tag_encap_proto(skb->data);
> }
>
> +static struct sk_buff *ar9331_tag_gro_receive(struct list_head *head,
> + struct sk_buff *skb)
> +{
> + const struct packet_offload *ptype;
> + struct sk_buff *p, *pp = NULL;
> + u32 data_off, data_end;
> + const u8 *data;
> + int flush = 1;
> +
> + data_off = skb_gro_offset(skb);
> + data_end = data_off + AR9331_HDR_LEN;
AR9331_HDR_LEN is a parameter here which is incidentally
dsa_device_ops::overhead.
> +
> + data = skb_gro_header_fast(skb, data_off);
> + if (skb_gro_header_hard(skb, data_end)) {
> + data = skb_gro_header_slow(skb, data_end, data_off);
> + if (unlikely(!data))
> + goto out;
> + }
> +
> + /* Data that is to the left from the current position is already
> + * pulled to the head
> + */
> + if (unlikely(!ar9331_tag_sanity_check(skb->data + data_off)))
> + goto out;
This is applicable to all taggers, they need to verify the sanity of the
header they are being handed.
> +
> + rcu_read_lock();
> +
> + ptype = gro_find_receive_by_type(ar9331_tag_encap_proto(data));
If there is no encapsulation a tagger can return the frame's protocol
directly, so similarly the tagger can be interrogated for returning that.
> + if (!ptype)
> + goto out_unlock;
> +
> + flush = 0;
> +
> + list_for_each_entry(p, head, list) {
> + if (!NAPI_GRO_CB(p)->same_flow)
> + continue;
> +
> + if (ar9331_tag_source_port(skb->data + data_off) ^
> + ar9331_tag_source_port(p->data + data_off))
Similarly here, the tagger could provide a function whose job is to
return the port number from within its own tag.
So with that being said, what do you think about building a tagger
abstraction which is comprised of:
- header length which is dsa_device_ops::overhead
- validate_tag()
- get_tag_encap_proto()
- get_port_number()
and the rest is just wrapping the general GRO list manipulation?
Also, I am wondering should we somehow expose the DSA master
net_device's napi_struct such that we could have the DSA slave
net_devices call napi_gro_receive() themselves directly such that they
could also perform additional GRO on top of Ethernet frames?
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-12-30 18:21 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-30 14:30 [PATCH RFC net-next 00/20] net: dsa: add GRO support Alexander Lobakin
2019-12-30 14:30 ` [PATCH RFC net-next 01/19] net: dsa: make .flow_dissect() callback returning void Alexander Lobakin
2019-12-30 18:11 ` Florian Fainelli
2019-12-30 14:30 ` [PATCH RFC net-next 02/19] net: dsa: add GRO support infrastructure Alexander Lobakin
2019-12-30 14:30 ` [PATCH RFC net-next 03/19] net: dsa: tag_ar9331: add .flow_dissect() callback Alexander Lobakin
2019-12-30 18:22 ` Florian Fainelli
2019-12-30 14:30 ` [PATCH RFC net-next 04/19] net: dsa: tag_ar9331: split out common tag accessors Alexander Lobakin
2019-12-30 17:18 ` Andrew Lunn
2019-12-30 14:30 ` [PATCH RFC net-next 05/19] net: dsa: tag_ar9331: add GRO callbacks Alexander Lobakin
2019-12-30 18:20 ` Florian Fainelli [this message]
2019-12-30 20:36 ` Andrew Lunn
2020-01-13 9:21 ` Alexander Lobakin
2020-01-13 9:42 ` Vladimir Oltean
2020-01-13 9:46 ` Alexander Lobakin
2020-01-13 10:28 ` Vladimir Oltean
2020-01-14 21:56 ` Florian Fainelli
2020-01-15 7:38 ` Alexander Lobakin
2020-01-15 11:29 ` Alexander Lobakin
2019-12-30 14:30 ` [PATCH RFC net-next 06/19] net: dsa: tag_gswip: fix typo in tag name Alexander Lobakin
2019-12-30 17:22 ` Andrew Lunn
2020-01-14 21:57 ` Florian Fainelli
2020-01-15 7:24 ` Alexander Lobakin
2019-12-30 14:30 ` [PATCH RFC net-next 07/19] net: dsa: tag_gswip: switch to bitfield helpers Alexander Lobakin
2019-12-30 14:30 ` [PATCH RFC net-next 08/19] net: dsa: tag_gswip: add .flow_dissect() callback Alexander Lobakin
2019-12-30 14:30 ` [PATCH RFC net-next 09/19] net: dsa: tag_gswip: split out common tag accessors Alexander Lobakin
2019-12-30 14:30 ` [PATCH RFC net-next 10/19] net: dsa: tag_gswip: add GRO callbacks Alexander Lobakin
2019-12-30 14:30 ` [PATCH RFC net-next 11/19] net: dsa: tag_lan9303: add .flow_dissect() callback Alexander Lobakin
2019-12-30 14:30 ` [PATCH RFC net-next 12/19] net: dsa: tag_lan9303: split out common tag accessors Alexander Lobakin
2019-12-30 14:30 ` [PATCH RFC net-next 13/19] net: dsa: tag_lan9303: add GRO callbacks Alexander Lobakin
2019-12-30 14:30 ` [PATCH RFC net-next 14/19] net: dsa: tag_mtk: split out common tag accessors Alexander Lobakin
2019-12-30 14:30 ` [PATCH RFC net-next 15/19] net: dsa: tag_mtk: add GRO callbacks Alexander Lobakin
2019-12-30 14:30 ` [PATCH RFC net-next 16/19] net: dsa: tag_qca: fix doubled Tx statistics Alexander Lobakin
2019-12-30 17:23 ` Andrew Lunn
2020-01-14 21:57 ` Florian Fainelli
2019-12-30 14:30 ` [PATCH RFC net-next 17/19] net: dsa: tag_qca: switch to bitfield helpers Alexander Lobakin
2019-12-30 14:30 ` [PATCH RFC net-next 18/19] net: dsa: tag_qca: split out common tag accessors Alexander Lobakin
2019-12-30 14:30 ` [PATCH RFC net-next 19/19] net: dsa: tag_qca: add GRO callbacks Alexander Lobakin
2019-12-30 14:30 ` [PATCH RFC net-next 20/20] net: core: add (unlikely) DSA support in napi_gro_frags() Alexander Lobakin
2019-12-30 17:12 ` [PATCH RFC net-next 00/20] net: dsa: add GRO support Andrew Lunn
2020-01-13 9:25 ` Alexander Lobakin
2019-12-31 15:32 ` Vladimir Oltean
2020-01-13 9:30 ` Alexander Lobakin
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=ee6f83fd-edf4-5a98-9868-4cbe9e226b9b@gmail.com \
--to=f.fainelli@gmail.com \
--cc=alobakin@dlink.ru \
--cc=andrew@lunn.ch \
--cc=ap420073@gmail.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=ecree@solarflare.com \
--cc=edumazet@google.com \
--cc=hauke@hauke-m.de \
--cc=jakub.kicinski@netronome.com \
--cc=jakub@cloudflare.com \
--cc=jiri@mellanox.com \
--cc=komachi.yoshiki@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=mcroce@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=paulb@mellanox.com \
--cc=sdf@google.com \
--cc=sean.wang@mediatek.com \
--cc=songliubraving@fb.com \
--cc=stephen@networkplumber.org \
--cc=vivien.didelot@gmail.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;
as well as URLs for NNTP newsgroup(s).