Re: [RFC PATCH net-next] ppp: don't store tx skb in the fastpath

[Vadim Fedorenko]

On 09/02/2026 02:11, Qingfang Deng wrote:
> Currently, ppp->xmit_pending is used in ppp_send_frame() to pass a skb
> to ppp_push(), and holds the skb when a PPP channel cannot immediately
> transmit it. This state is redundant because the transmit queue
> (ppp->file.xq) can already handle the backlog. Furthermore, during
> normal operation, an skb is queued in file.xq only to be immediately
> dequeued, causing unnecessary overhead.
>
> Refactor the transmit path to avoid stashing the skb when possible:
> - Remove ppp->xmit_pending.
> - Rename ppp_send_frame() to ppp_prepare_tx_skb(), and don't call
>    ppp_push() in it. It returns 1 if the skb is consumed
>    (dropped/handled) or 0 if it can be passed to ppp_push().
> - Update ppp_push() to accept the skb. It returns 1 if the skb is
>    consumed, or 0 if the channel is busy.
> - Optimize __ppp_xmit_process():
>    - Fastpath: If the queue is empty, attempt to send the skb directly
>      via ppp_push(). If busy, queue it.
>    - Slowpath: If the queue is not empty, or fastpath failed, process
>      the backlog in file.xq. Split dequeueing loop into a separate
>      function ppp_xmit_flush() so ppp_channel_push() uses that directly
>      instead of passing a NULL skb to __ppp_xmit_process().
>
> This simplifies the states and reduces locking in the fastpath.

Quite insteresting optimization. Did you measure the improvements? Like
pps over PPP interface, or the length of backlog at some ppp rate?