archive mirror
 help / color / mirror / Atom feed
From: Vladimir Oltean <>
To: Christian Eggers <>
Cc: Andrew Lunn <>,
	Vivien Didelot <>,
	Florian Fainelli <>,
	Jakub Kicinski <>,
	Kurt Kanzenbach <>,
	"David S . Miller" <>,
	Woojung Huh <>,
	Microchip Linux Driver Support <>,,
Subject: Re: [PATCH net-next 1/3] net: dsa: don't pass cloned skb's to drivers xmit function
Date: Sun, 18 Oct 2020 00:35:50 +0300	[thread overview]
Message-ID: <20201017213550.5qgiy7tpydutxkis@skbuf> (raw)
In-Reply-To: <1735006.IpzxAEH60n@n95hx1g2>

On Sat, Oct 17, 2020 at 10:56:24PM +0200, Christian Eggers wrote:
> The status page seems to be out of date:

Yeah, it can do that sometimes. Extremely rarely, but it happens. But
net-next is still closed, nonetheless.

> The FAQ says: "Do not send new net-next content to netdev...". So there is no
> possibility for code review, is it?

You can always send patches as RFC (Request For Comments). In fact
that's what I'm going to do right now.

> > - Actually I was asking you this because sja1105 PTP no longer works
> >   after this change, due to the change of txflags.
> The tail taggers seem to be immune against this change.


> > Do you want me to try and send a version using pskb_expand_head and you
> > can test if it works for your tail-tagging switch?
> I already wanted to ask... My 2nd try (checking for !skb_cloned()) was already
> sufficient (for me). Hacking linux-net is very interesting, but I have many
> other items open... Testing would be no problem.

Ok, incoming.....

> > I think it would be best to use the unlikely(tail_tag) approach though.
> > The reallocation function should still be in the common code path. Even
> > for a non-1588 switch, there are other code paths that clone packets on
> > TX. For example, the bridge does that, when flooding packets.
> You already mentioned that you don't want to pass cloned packets to the tag
> drivers xmit() functions. I've no experience with the problems caused by
> cloned packets, but would cloned packets work anyway? Or must cloned packets
> not be changed (e.g. by tail-tagging)? Is there any value in first cloning in
> dsa_skb_tx_timestamp() and then unsharing in dsa_slave_xmit a few lines later?
> The issue I currently have only affects a very minor number of packets (cloned
> AND < ETH_ZLEN AND CONFIG_SLOB), so only these packets would need a copying.

Yes, we need to clone and then unshare immediately afterwards because
sja1105_xmit calls sja1105_defer_xmit, which schedules a workqueue. The
sja1105 driver assumes that the skb has already been cloned by then. So
basically, the sja1105 driver introduces a strict ordering requirement
that dsa_skb_tx_timestamp needs to be first, then p->xmit second. So we
necessarily must reallocate freshly cloned skbs, as things stand now.
I'll think about avoiding that, but not now. We were always reallocating
those frames before, using skb_cow_head. The only difference now is that
the skb, as it is passed to the tagger's xmit() function, is directly
writable. You'll see...

  reply	other threads:[~2020-10-17 21:35 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
2020-10-17 19:12       ` Vladimir Oltean
2020-10-17 20:56         ` Christian Eggers
2020-10-17 21:35           ` Vladimir Oltean [this message]
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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201017213550.5qgiy7tpydutxkis@skbuf \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH net-next 1/3] net: dsa: don'\''t pass cloned skb'\''s to drivers xmit function' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).