Re: [PATCH net-next v3] ppp: enable TX scatter-gather
Qingfang Deng <[email protected]> Wed, 28 Jan 2026 17:19:54 +0800
| Newsgroups | org.kernel.vger.linux-ppp,org.kernel.vger.linux-kernel,org.kernel.vger.netdev |
|---|---|
| Message-ID | <CALW65jZVB=+Q89Q7CjfngUyski1F5dCfbdGZdxe3no76Stv0_A@mail.gmail.com> |
On Wed, Jan 28, 2026 at 5:05 PM Paolo Abeni <[email protected]> wrote: > > On Tue, Jan 27, 2026 at 8:34 PM Paolo Abeni <[email protected]> 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). > > Correct. > > > 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? > > AFAICS nothing prevent the user-space from creating multiple channels > with different type even without SC_MULTILINK, so ppp_fix_features() > should likely check the whole channel list. > > Also packets could be being transmitted after channel creation and > before the features are updated, so ppp_start_xmit could observe > transient mismatching features and skb layout. > > It's not a matter of bad performances: if skb is not linear and the > channel start_xmit assumes linear layout bad things will happen. I think > that even with a correct ppp_fix_features() you will need to check for > linearization in the datapath (as an unlikely condition). Fair enough. I'll send v4 with your proposed changes. Regards, Qingfang