[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CALW65jYb0prfB-KpxdcNVHB1tBjN3tW286BsvQkCFoXwTu2QKw@mail.gmail.com>
Date: Tue, 27 Jan 2026 22:31:13 +0800
From: Qingfang Deng <dqfext@...il.com>
To: Paolo Abeni <pabeni@...hat.com>
Cc: Andrew Lunn <andrew+netdev@...n.ch>, "David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, linux-ppp@...r.kernel.org,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
Toke Høiland-Jørgensen <toke@...hat.com>
Subject: Re: [PATCH net-next v3] ppp: enable TX scatter-gather
Hi Paolo,
On Tue, Jan 27, 2026 at 8:34 PM Paolo Abeni <pabeni@...hat.com> wrote:
> I spent a little time trying to understanding the logic here and I think
> that enabling features depending on IFF_NO_QUEUE is fragile at best.
>
> It looks like that the IFF_NO_QUEUE bit is an inconsistent state for
> multilink devices using different type of channels.
> Moreover the user-space could attaching a qdisc to the ppp device after
> channel initialization.
>
> Instead you could always expose the features and linearize as needed
> when transmitting on !direct_xmit channel; no need to touch the
> individual channel implementation, you could do such check before
> calling the ops->start_xmit() calls (possibly creating a new
> wrapper/helper for that).
Attaching a new qdisc won't clear the IFF_NO_QUEUE bit. (The flag
means the interface _can_ run without a qdisc).
As for multilink devices, one is not supposed to bundle channels with
inconsistent direct_xmit (for example, mix ppp_synctty with pptp) and
expect better results. But as the driver does not reject that, I may
add a skb_linearize() to ppp_mp_explode(), or add a check for
SC_MULTILINK flag in ppp_fix_features().
What do you think?
Regards,
Qingfang
Powered by blists - more mailing lists