Re: [PATCH] net: af_packet: add af_packet hrtimer mode

[Eric Dumazet]

On Thu, Aug 7, 2025 at 10:07 PM Xin Zhao <jackzxcui1989@xxxxxxx> wrote:
>
> On Wed, 2025-08-06 at 16:51 +0800, Ferenc wrote:
>
> > I doubt we need another CONFIG option ?
> >
> > Also this seems to be beneficial for HZ=100 or HZ=250 configuration,
> > maybe worth mentioning in the changelog.
> >
> > But more importantly, I think you should explain what difference this
> > really makes,
> > in which circumstances this timer needs to fire...
> >
> > If real-time is a concern, maybe using a timer to perform GC-style operation
> > is a no go anyway...
>
> Dear Eric,
>
> I've thought about it, and I really didn't foresee any obvious drawbacks
> after switching to hrtimer, so in PATCH v1, I removed that config and directly
> changed it to hrtimer.
> As you mentioned, this issue is indeed more pronounced on systems with HZ=250
> or HZ=100. Our testing environment was also based on a system with HZ=250,
> which is still quite common in embedded systems.
>
> Regarding the benefits of using hrtimer, I already provided the test data and
> testing environment in my previous reply to Ferenc, and the improvements are
> quite significant.
>
> As for when the retire timer expires, I've reviewed this logic. From my
> perspective, the existing mechanism in AF_PACKET is complete. In the
> prb_retire_rx_blk_timer_expired function, there is a check to see if there are
> any packets in the current block. If there are packets, the status will be
> reported to user space. By switching to hrtimer, I aimed to ensure that the
> timeout handling in the prb_retire_rx_blk_timer_expired function can be
> executed in a more timely manner.
>

I have some doubts why AF_PACKET timer would be involved in the performance
of an application.

Are you sure about your requirements ?

I do not know what application you are running, but I wonder if using
TX timestamps,
and EDT model to deliver your packets in a more accurate way would be better.

Some qdiscs already use hrtimer and get sub 50 usec latency out of the box,
or whatever time a cpu sleeping in deep state takes to wake up.


> Thanks
> Xin Zhao
>