netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christian Eggers <ceggers@arri.de>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
	Vivien Didelot <vivien.didelot@gmail.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Jakub Kicinski <kuba@kernel.org>,
	Kurt Kanzenbach <kurt@linutronix.de>,
	"David S . Miller" <davem@davemloft.net>,
	Woojung Huh <woojung.huh@microchip.com>,
	"Microchip Linux Driver Support" <UNGLinuxDriver@microchip.com>,
	<netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH net-next 1/3] net: dsa: don't pass cloned skb's to drivers xmit function
Date: Sat, 17 Oct 2020 20:53:19 +0200	[thread overview]
Message-ID: <2130539.dlFve3NVyK@n95hx1g2> (raw)
In-Reply-To: <20201017004816.q4l6cypw4fd4vu5f@skbuf>

Hi Vladimir,

On Saturday, 17 October 2020, 02:48:16 CEST, Vladimir Oltean wrote:
> On Fri, Oct 16, 2020 at 10:02:24PM +0200, Christian Eggers wrote:
> > Ensure that the skb is not cloned and has enough tail room for the tail
> > tag. This code will be removed from the drivers in the next commits.
> > 
> > Signed-off-by: Christian Eggers <ceggers@arri.de>
> > ---
> 
> Does 1588 work for you using this change, or you haven't finished
> implementing it yet? If you haven't, I would suggest finishing that
> part first.
Yes it does. Just after finishing this topic, I would to sent the patches for
PTP. Maybe I'll do it in parallel, anything but the combination of L2/E2E/SLOB
seems to work.

> The post-reallocation skb looks nothing like the one before.
> 
> Before:
> skb len=68 headroom=2 headlen=68 tailroom=186
> mac=(2,14) net=(16,-1) trans=-1
> shinfo(txflags=1 nr_frags=0 gso(size=0 type=0 segs=0))
> csum(0x0 ip_summed=0 complete_sw=0 valid=0 level=0)
> hash(0x9d6927ec sw=1 l4=0) proto=0x88f7 pkttype=0 iif=0
> dev name=swp2 feat=0x0x0002000000005020
> sk family=17 type=3 proto=0
> 
> After:
> skb len=68 headroom=2 headlen=68 tailroom=186
> mac=(2,16) net=(18,-17) trans=1
> shinfo(txflags=0 nr_frags=0 gso(size=0 type=0 segs=0))
> csum(0x0 ip_summed=0 complete_sw=0 valid=0 level=0)
> hash(0x0 sw=0 l4=0) proto=0x0000 pkttype=0 iif=0
> 
> Notice how you've changed shinfo(txflags), among other things.

I get a similar output when placing the two skb_dump() calls in the current
ksz_common_xmit() code:

[ 5052.662168] old:skb len=58 headroom=2 headlen=58 tailroom=68
[ 5052.662168] mac=(2,14) net=(16,-1) trans=-1
[ 5052.662168] shinfo(txflags=1 nr_frags=0 gso(size=0 type=0 segs=0))
[ 5052.662168] csum(0x0 ip_summed=0 complete_sw=0 valid=0 level=0)
[ 5052.662168] hash(0x0 sw=0 l4=0) proto=0x88f7 pkttype=0 iif=0
[ 5052.676360] old:dev name=lan0 feat=0x0x0002000000005220
[ 5052.679001] old:sk family=17 type=3 proto=0
[ 5052.681140] old:skb linear:   00000000: 01 1b 19 00 00 00 52 d9 a9 5d a1 40 88 f7 01 02
[ 5052.685236] old:skb linear:   00000010: 00 2c 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 5052.689342] old:skb linear:   00000020: 00 00 52 d9 a9 ff fe 5d a1 40 00 01 00 00 01 7f
[ 5052.693418] old:skb linear:   00000030: 00 00 00 00 00 00 00 00 00 00
[ 5052.696843] new:skb len=65 headroom=2 headlen=65 tailroom=61
[ 5052.696843] mac=(2,16) net=(18,-17) trans=1
[ 5052.696843] shinfo(txflags=0 nr_frags=0 gso(size=0 type=0 segs=0))
[ 5052.696843] csum(0x0 ip_summed=0 complete_sw=0 valid=0 level=0)
[ 5052.696843] hash(0x0 sw=0 l4=0) proto=0x0000 pkttype=0 iif=0
[ 5052.711215] new:skb linear:   00000000: 01 1b 19 00 00 00 52 d9 a9 5d a1 40 88 f7 01 02
[ 5052.715305] new:skb linear:   00000010: 00 2c 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 5052.719407] new:skb linear:   00000020: 00 00 52 d9 a9 ff fe 5d a1 40 00 01 00 00 01 7f
[ 5052.723484] new:skb linear:   00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 5052.727587] new:skb linear:   00000040: 00


Note that whilst some skb members differ, the two hexdumps look correct.

> Which proves that you can't just copy&paste whatever you found in
> tag_trailer.c.
I did. tag_trailer and tag_ksz are quite similar here, so I took a combination of them.

> I am not yet sure whether there is any helper that can be used instead
> of this crazy open-coding. Right now, not having tested anything yet, my
> candidates of choice would be pskb_expand_head or __pskb_pull_tail. You
> should probably also try to cater here for the potential reallocation
> done in the skb_cow_head() of non-tail taggers. Which would lean the
> balance towards pskb_expand_head(), I believe.
The "open coding" is from the existing code (which doesn't say that it is
correct). I will investigate why the copied skb is different and whether 
psk_expand_head can do better.

I don't like to touch the non-tail taggers, this is too much out of the scope
of my current work.

> Also, if the result is going to be longer than ~20 lines of code, I
> strongly suggest moving the reallocation to a separate function so you
> don't clutter dsa_slave_xmit.
As Florian requested I'll likely put the code into a separate function in
slave.c and call it from the individual tail-taggers in order not to put 
extra conditionals in dsa_slave_xmit.

regards
Christian




  reply	other threads:[~2020-10-17 18:54 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-16 20:02 [PATCH 0/3] net: dsa: move skb reallocation to dsa_slave_xmit Christian Eggers
2020-10-16 20:02 ` [PATCH net-next 1/3] net: dsa: don't pass cloned skb's to drivers xmit function Christian Eggers
2020-10-17  0:48   ` Vladimir Oltean
2020-10-17 18:53     ` Christian Eggers [this message]
2020-10-17 19:12       ` Vladimir Oltean
2020-10-17 20:56         ` Christian Eggers
2020-10-17 21:35           ` Vladimir Oltean
2020-10-17  2:35   ` Florian Fainelli
2020-10-16 20:02 ` [PATCH net-next 2/3] net: dsa: tag_ksz: don't allocate additional memory for padding/tagging Christian Eggers
2020-10-16 20:02 ` [PATCH net-next 3/3] net: dsa: trailer: " Christian Eggers
2020-10-17  2:44 ` [PATCH 0/3] net: dsa: move skb reallocation to dsa_slave_xmit Florian Fainelli

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=2130539.dlFve3NVyK@n95hx1g2 \
    --to=ceggers@arri.de \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=kuba@kernel.org \
    --cc=kurt@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=vivien.didelot@gmail.com \
    --cc=woojung.huh@microchip.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).