mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ferenc Fejes <ferenc@fejes.dev>
To: Xin Zhao <jackzxcui1989@163.com>,
	willemdebruijn.kernel@gmail.com,  edumazet@google.com
Cc: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com,
	horms@kernel.org, 	netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] net: af_packet: add af_packet hrtimer mode
Date: Fri, 08 Aug 2025 13:39:46 +0200	[thread overview]
Message-ID: <6183a3b8884fa1ba006174d63ffb1a6924735740.camel@fejes.dev> (raw)
In-Reply-To: <20250808043300.77995-1-jackzxcui1989@163.com>

Dear Xin,

On Fri, 2025-08-08 at 12:33 +0800, Xin Zhao wrote:
> On Wed, 2025-08-06 at 15:25 +0800, Ferenc wrote:
> 
> > Do you have performance numbers? It would be nice to see the test
> > environment,
> > measurements carried out and some latency/jitter numbers.
> 
> Dear Ferenc,
> 
> We test it on 6.1.134 rt-linux version, we set 2ms as the retire timeout, the
> following test result describe the packet details including cur_ts_us(time
> when
> the sample code handle the packet) and cur_pk_ts_us(time when the packet send)
> and delay(time unit is us, the gap between cur_ts_us and cur_pk_ts_us).

Thanks for the additional details. Out of curiosity, how do your setup looks
like? The packet received from the LIDAR device are
A) processed on the system
B) processed on the system and transmitted elsewhere
C) only transmitted elsewhere

From the details provided so far I'm unable to understand the setup you have.
Both 2ms and 8ms looks pretty high for me. For example on a loaded system, I
have seen ~200-300us latencies with AF_PACKET software switch P95 with soma rare
outliers over 1ms. But that system might be faster than a embedded device you
have.

> Test result before change to hrtimer:
> --------num_pkts:54--------
> pack_size_:902, atx_udp_seq:86152515, cur_ts_us:[1749707679501254],
> cur_pkg_ts_us:[1749707679492443], delay:8811
> pack_size_:902, atx_udp_seq:86152516, cur_ts_us:[1749707679501260],
> cur_pkg_ts_us:[1749707679492590], delay:8670
> pack_size_:902, atx_udp_seq:86152517, cur_ts_us:[1749707679501266],
> cur_pkg_ts_us:[1749707679492737], delay:8529
> pack_size_:902, atx_udp_seq:86152518, cur_ts_us:[1749707679501274],
> cur_pkg_ts_us:[1749707679492884], delay:8391
> ...
> Test result after change to hrtimer:
> --------num_pkts:14--------
> pack_size_:902, atx_udp_seq:42679600, cur_ts_us:[1750220805104634],
> cur_pkg_ts_us:[1750220805101776], delay:2858
> pack_size_:902, atx_udp_seq:42679601, cur_ts_us:[1750220805104635],
> cur_pkg_ts_us:[1750220805101923], delay:2712
> pack_size_:902, atx_udp_seq:42679602, cur_ts_us:[1750220805104636],
> cur_pkg_ts_us:[1750220805102074], delay:2562
> pack_size_:902, atx_udp_seq:42679603, cur_ts_us:[1750220805104638],
> cur_pkg_ts_us:[1750220805102223], delay:2415

These timestamps calculated like this for example?:

sk = socket(AF_PACKET, ...)
cur_ts_us = now();
send(pkt, sk)
cur_pkg_ts_us = now()

> ...
> In our system, we care about the delay value, cpu usage and context switches.
> Use af_packet the cpu usage of the lidar process change from about 16.91% to 
> 12.92%, the context switches change from about 900+ per second to 400+ per
> second. The benefits of using AF_PACKET are significant enough that we need
> to adopt it. After using hrtimer instead of timer, the impact of the delay
> has also been controlled, which is what we hoped for.
> 
> Thanks
> Xin Zhao
> 

Thanks,
Ferenc

  reply	other threads:[~2025-08-08 11:39 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-08  4:33 Xin Zhao
2025-08-08 11:39 ` Ferenc Fejes [this message]
  -- strict thread matches above, loose matches on Subject: below --
2025-08-09  8:57 Xin Zhao
2025-08-08  7:28 Xin Zhao
2025-08-08  5:06 Xin Zhao
2025-08-08  6:01 ` Eric Dumazet
2025-08-06  5:52 Xin Zhao
2025-08-06  7:24 ` Ferenc Fejes
2025-08-06  8:51 ` Eric Dumazet
2025-08-06 20:28 ` kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6183a3b8884fa1ba006174d63ffb1a6924735740.camel@fejes.dev \
    --to=ferenc@fejes.dev \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=jackzxcui1989@163.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=willemdebruijn.kernel@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®