Re: [PATCH net-next v3] ppp: enable TX scatter-gather

On 1/27/26 3:31 PM, Qingfang Deng wrote:
> Hi Paolo,
> 
> 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).

/P