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

On Mon, Feb 9, 2026 at 7:17 PM Vadim Fedorenko
<[email protected]> wrote:
> 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?

Not yet. I may test it with PPPoE when I have access to a network
traffic generator tomorrow.