From: "Abdul Rahim, Faizal" <faizal.abdul.rahim@linux.intel.com>
To: Song Yoong Siang <yoong.siang.song@intel.com>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
Willem de Bruijn <willemb@google.com>,
Florian Bezdeka <florian.bezdeka@siemens.com>,
Donald Hunter <donald.hunter@gmail.com>,
Jonathan Corbet <corbet@lwn.net>, Bjorn Topel <bjorn@kernel.org>,
Magnus Karlsson <magnus.karlsson@intel.com>,
Maciej Fijalkowski <maciej.fijalkowski@intel.com>,
Jonathan Lemon <jonathan.lemon@gmail.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Jesper Dangaard Brouer <hawk@kernel.org>,
John Fastabend <john.fastabend@gmail.com>,
Joe Damato <jdamato@fastly.com>,
Stanislav Fomichev <sdf@fomichev.me>,
Xuan Zhuo <xuanzhuo@linux.alibaba.com>,
Mina Almasry <almasrymina@google.com>,
Daniel Jurgens <danielj@nvidia.com>,
Andrii Nakryiko <andrii@kernel.org>,
Eduard Zingerman <eddyz87@gmail.com>,
Mykola Lysenko <mykolal@fb.com>,
Martin KaFai Lau <martin.lau@linux.dev>,
Song Liu <song@kernel.org>,
Yonghong Song <yonghong.song@linux.dev>,
KP Singh <kpsingh@kernel.org>, Hao Luo <haoluo@google.com>,
Jiri Olsa <jolsa@kernel.org>, Shuah Khan <shuah@kernel.org>,
Alexandre Torgue <alexandre.torgue@foss.st.com>,
Jose Abreu <joabreu@synopsys.com>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
Tony Nguyen <anthony.l.nguyen@intel.com>,
Przemek Kitszel <przemyslaw.kitszel@intel.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org, bpf@vger.kernel.org,
linux-kselftest@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
intel-wired-lan@lists.osuosl.org, xdp-hints@xdp-project.net
Subject: Re: [PATCH bpf-next v6 4/4] igc: Add launch time support to XDP ZC
Date: Mon, 20 Jan 2025 14:25:45 +0800 [thread overview]
Message-ID: <84770113-2546-4035-8bd4-bf9cedcfb00f@linux.intel.com> (raw)
In-Reply-To: <20250116155350.555374-5-yoong.siang.song@intel.com>
Hi Siang.
On 16/1/2025 11:53 pm, Song Yoong Siang wrote:
> Enable Launch Time Control (LTC) support to XDP zero copy via XDP Tx
> metadata framework.
>
> This patch is tested with tools/testing/selftests/bpf/xdp_hw_metadata on
> Intel I225-LM Ethernet controller. Below are the test steps and result.
>
> Test Steps:
> 1. At DUT, start xdp_hw_metadata selftest application:
> $ sudo ./xdp_hw_metadata enp2s0 -l 1000000000 -L 1
>
> 2. At Link Partner, send an UDP packet with VLAN priority 1 to port 9091 of
> DUT.
>
> When launch time is set to 1s in the future, the delta between launch time
> and transmit hardware timestamp is equal to 0.016us, as shown in result
> below:
> 0x562ff5dc8880: rx_desc[4]->addr=84110 addr=84110 comp_addr=84110 EoP
> rx_hash: 0xE343384 with RSS type:0x1
> HW RX-time: 1734578015467548904 (sec:1734578015.4675) delta to User RX-time sec:0.0002 (183.103 usec)
> XDP RX-time: 1734578015467651698 (sec:1734578015.4677) delta to User RX-time sec:0.0001 (80.309 usec)
> No rx_vlan_tci or rx_vlan_proto, err=-95
> 0x562ff5dc8880: ping-pong with csum=561c (want c7dd) csum_start=34 csum_offset=6
> HW RX-time: 1734578015467548904 (sec:1734578015.4675) delta to HW Launch-time sec:1.0000 (1000000.000 usec)
> 0x562ff5dc8880: complete tx idx=4 addr=4018
> HW Launch-time: 1734578016467548904 (sec:1734578016.4675) delta to HW TX-complete-time sec:0.0000 (0.016 usec)
> HW TX-complete-time: 1734578016467548920 (sec:1734578016.4675) delta to User TX-complete-time sec:0.0000 (32.546 usec)
> XDP RX-time: 1734578015467651698 (sec:1734578015.4677) delta to User TX-complete-time sec:0.9999 (999929.768 usec)
> HW RX-time: 1734578015467548904 (sec:1734578015.4675) delta to HW TX-complete-time sec:1.0000 (1000000.016 usec)
> 0x562ff5dc8880: complete rx idx=132 addr=84110
To be cautious, could we perform a stress test by sending a higher number
of packets with launch time? For example, we could send 200 packets, each
configured with a launch time, and verify that the driver continues to
function correctly afterward.
> Signed-off-by: Song Yoong Siang <yoong.siang.song@intel.com>
> ---
> drivers/net/ethernet/intel/igc/igc_main.c | 78 ++++++++++++++++-------
> 1 file changed, 56 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/igc/igc_main.c b/drivers/net/ethernet/intel/igc/igc_main.c
> index 27872bdea9bd..6857f5f5b4b2 100644
> --- a/drivers/net/ethernet/intel/igc/igc_main.c
> +++ b/drivers/net/ethernet/intel/igc/igc_main.c
> @@ -1566,6 +1566,26 @@ static bool igc_request_tx_tstamp(struct igc_adapter *adapter, struct sk_buff *s
> return false;
> }
>
> +static void igc_insert_empty_packet(struct igc_ring *tx_ring)
> +{
> + struct igc_tx_buffer *empty_info;
> + struct sk_buff *empty;
> + void *data;
> +
> + empty_info = &tx_ring->tx_buffer_info[tx_ring->next_to_use];
> + empty = alloc_skb(IGC_EMPTY_FRAME_SIZE, GFP_ATOMIC);
> + if (!empty)
> + return;
> +
> + data = skb_put(empty, IGC_EMPTY_FRAME_SIZE);
> + memset(data, 0, IGC_EMPTY_FRAME_SIZE);
> +
> + igc_tx_ctxtdesc(tx_ring, 0, false, 0, 0, 0);
> +
> + if (igc_init_tx_empty_descriptor(tx_ring, empty, empty_info) < 0)
> + dev_kfree_skb_any(empty);
> +}
> +
The function igc_insert_empty_packet() appears to wrap existing code to
enhance reusability, with no new changes related to enabling launch-time
XDP ZC functionality. If so, could we split this into a separate commit?
This would make it clearer for the reader to distinguish between the
refactoring changes and the new changes related to enabling launch-time XDP
ZC support.
> static netdev_tx_t igc_xmit_frame_ring(struct sk_buff *skb,
> struct igc_ring *tx_ring)
> {
> @@ -1603,26 +1623,8 @@ static netdev_tx_t igc_xmit_frame_ring(struct sk_buff *skb,
> skb->tstamp = ktime_set(0, 0);
> launch_time = igc_tx_launchtime(tx_ring, txtime, &first_flag, &insert_empty);
>
> - if (insert_empty) {
> - struct igc_tx_buffer *empty_info;
> - struct sk_buff *empty;
> - void *data;
> -
> - empty_info = &tx_ring->tx_buffer_info[tx_ring->next_to_use];
> - empty = alloc_skb(IGC_EMPTY_FRAME_SIZE, GFP_ATOMIC);
> - if (!empty)
> - goto done;
> -
> - data = skb_put(empty, IGC_EMPTY_FRAME_SIZE);
> - memset(data, 0, IGC_EMPTY_FRAME_SIZE);
> -
> - igc_tx_ctxtdesc(tx_ring, 0, false, 0, 0, 0);
> -
> - if (igc_init_tx_empty_descriptor(tx_ring,
> - empty,
> - empty_info) < 0)
> - dev_kfree_skb_any(empty);
> - }
> + if (insert_empty)
> + igc_insert_empty_packet(tx_ring);
>
> done:
> /* record the location of the first descriptor for this packet */
> @@ -2955,9 +2957,33 @@ static u64 igc_xsk_fill_timestamp(void *_priv)
> return *(u64 *)_priv;
> }
>
> +static void igc_xsk_request_launch_time(u64 launch_time, void *_priv)
> +{
> + struct igc_metadata_request *meta_req = _priv;
> + struct igc_ring *tx_ring = meta_req->tx_ring;
> + __le32 launch_time_offset;
> + bool insert_empty = false;
> + bool first_flag = false;
> +
> + if (!tx_ring->launchtime_enable)
> + return;
> +
> + launch_time_offset = igc_tx_launchtime(tx_ring,
> + ns_to_ktime(launch_time),
> + &first_flag, &insert_empty);
> + if (insert_empty) {
> + igc_insert_empty_packet(tx_ring);
> + meta_req->tx_buffer =
> + &tx_ring->tx_buffer_info[tx_ring->next_to_use];
> + }
> +
> + igc_tx_ctxtdesc(tx_ring, launch_time_offset, first_flag, 0, 0, 0);
> +}
> +
> const struct xsk_tx_metadata_ops igc_xsk_tx_metadata_ops = {
> .tmo_request_timestamp = igc_xsk_request_timestamp,
> .tmo_fill_timestamp = igc_xsk_fill_timestamp,
> + .tmo_request_launch_time = igc_xsk_request_launch_time,
> };
>
> static void igc_xdp_xmit_zc(struct igc_ring *ring)
> @@ -2980,7 +3006,7 @@ static void igc_xdp_xmit_zc(struct igc_ring *ring)
> ntu = ring->next_to_use;
> budget = igc_desc_unused(ring);
>
> - while (xsk_tx_peek_desc(pool, &xdp_desc) && budget--) {
> + while (xsk_tx_peek_desc(pool, &xdp_desc) && budget >= 4) {
Could we add some explanation on what & why the value "4" is used ?
WARNING: multiple messages have this Message-ID (diff)
From: "Abdul Rahim, Faizal" <faizal.abdul.rahim@linux.intel.com>
To: Song Yoong Siang <yoong.siang.song@intel.com>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
Willem de Bruijn <willemb@google.com>,
Florian Bezdeka <florian.bezdeka@siemens.com>,
Donald Hunter <donald.hunter@gmail.com>,
Jonathan Corbet <corbet@lwn.net>, Bjorn Topel <bjorn@kernel.org>,
Magnus Karlsson <magnus.karlsson@intel.com>,
Maciej Fijalkowski <maciej.fijalkowski@intel.com>,
Jonathan Lemon <jonathan.lemon@gmail.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Jesper Dangaard Brouer <hawk@kernel.org>,
John Fastabend <john.fastabend@gmail.com>,
Joe Damato <jdamato@fastly.com>,
Stanislav Fomichev <sdf@fomichev.me>,
Xuan Zhuo <xuanzhuo@linux.alibaba.com>,
Mina Almasry <almasrymina@google.com>,
Daniel Jurgens <danielj@nvidia.com>,
Andrii Nakryiko <andrii@kernel.org>,
Eduard Zingerman <eddyz87@gmail.com>,
Mykola Lysenko <mykolal@fb.com>,
Martin KaFai Lau <martin.lau@linux.dev>,
Song Liu <song@kernel.org>,
Yonghong Song <yonghong.song@linux.dev>,
KP Singh <kpsingh@kernel.org>, Hao Luo <haoluo@google.com>,
Jiri Olsa <jolsa@kernel.org>, Shuah Khan <shuah@kernel.org>,
Alexandre Torgue <alexandre.torgue@foss.st.com>,
Jose Abreu <joabreu@synopsys.com>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
Tony Nguyen <anthony.l.nguyen@intel.com>,
Przemek Kitszel <przemyslaw.kitszel@intel.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org, bpf@vger.kernel.org,
linux-kselftest@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
intel-wired-lan@lists.osuosl.org, xdp-hints@xdp-project.net
Subject: Re: [Intel-wired-lan] [PATCH bpf-next v6 4/4] igc: Add launch time support to XDP ZC
Date: Mon, 20 Jan 2025 14:25:45 +0800 [thread overview]
Message-ID: <84770113-2546-4035-8bd4-bf9cedcfb00f@linux.intel.com> (raw)
In-Reply-To: <20250116155350.555374-5-yoong.siang.song@intel.com>
Hi Siang.
On 16/1/2025 11:53 pm, Song Yoong Siang wrote:
> Enable Launch Time Control (LTC) support to XDP zero copy via XDP Tx
> metadata framework.
>
> This patch is tested with tools/testing/selftests/bpf/xdp_hw_metadata on
> Intel I225-LM Ethernet controller. Below are the test steps and result.
>
> Test Steps:
> 1. At DUT, start xdp_hw_metadata selftest application:
> $ sudo ./xdp_hw_metadata enp2s0 -l 1000000000 -L 1
>
> 2. At Link Partner, send an UDP packet with VLAN priority 1 to port 9091 of
> DUT.
>
> When launch time is set to 1s in the future, the delta between launch time
> and transmit hardware timestamp is equal to 0.016us, as shown in result
> below:
> 0x562ff5dc8880: rx_desc[4]->addr=84110 addr=84110 comp_addr=84110 EoP
> rx_hash: 0xE343384 with RSS type:0x1
> HW RX-time: 1734578015467548904 (sec:1734578015.4675) delta to User RX-time sec:0.0002 (183.103 usec)
> XDP RX-time: 1734578015467651698 (sec:1734578015.4677) delta to User RX-time sec:0.0001 (80.309 usec)
> No rx_vlan_tci or rx_vlan_proto, err=-95
> 0x562ff5dc8880: ping-pong with csum=561c (want c7dd) csum_start=34 csum_offset=6
> HW RX-time: 1734578015467548904 (sec:1734578015.4675) delta to HW Launch-time sec:1.0000 (1000000.000 usec)
> 0x562ff5dc8880: complete tx idx=4 addr=4018
> HW Launch-time: 1734578016467548904 (sec:1734578016.4675) delta to HW TX-complete-time sec:0.0000 (0.016 usec)
> HW TX-complete-time: 1734578016467548920 (sec:1734578016.4675) delta to User TX-complete-time sec:0.0000 (32.546 usec)
> XDP RX-time: 1734578015467651698 (sec:1734578015.4677) delta to User TX-complete-time sec:0.9999 (999929.768 usec)
> HW RX-time: 1734578015467548904 (sec:1734578015.4675) delta to HW TX-complete-time sec:1.0000 (1000000.016 usec)
> 0x562ff5dc8880: complete rx idx=132 addr=84110
To be cautious, could we perform a stress test by sending a higher number
of packets with launch time? For example, we could send 200 packets, each
configured with a launch time, and verify that the driver continues to
function correctly afterward.
> Signed-off-by: Song Yoong Siang <yoong.siang.song@intel.com>
> ---
> drivers/net/ethernet/intel/igc/igc_main.c | 78 ++++++++++++++++-------
> 1 file changed, 56 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/igc/igc_main.c b/drivers/net/ethernet/intel/igc/igc_main.c
> index 27872bdea9bd..6857f5f5b4b2 100644
> --- a/drivers/net/ethernet/intel/igc/igc_main.c
> +++ b/drivers/net/ethernet/intel/igc/igc_main.c
> @@ -1566,6 +1566,26 @@ static bool igc_request_tx_tstamp(struct igc_adapter *adapter, struct sk_buff *s
> return false;
> }
>
> +static void igc_insert_empty_packet(struct igc_ring *tx_ring)
> +{
> + struct igc_tx_buffer *empty_info;
> + struct sk_buff *empty;
> + void *data;
> +
> + empty_info = &tx_ring->tx_buffer_info[tx_ring->next_to_use];
> + empty = alloc_skb(IGC_EMPTY_FRAME_SIZE, GFP_ATOMIC);
> + if (!empty)
> + return;
> +
> + data = skb_put(empty, IGC_EMPTY_FRAME_SIZE);
> + memset(data, 0, IGC_EMPTY_FRAME_SIZE);
> +
> + igc_tx_ctxtdesc(tx_ring, 0, false, 0, 0, 0);
> +
> + if (igc_init_tx_empty_descriptor(tx_ring, empty, empty_info) < 0)
> + dev_kfree_skb_any(empty);
> +}
> +
The function igc_insert_empty_packet() appears to wrap existing code to
enhance reusability, with no new changes related to enabling launch-time
XDP ZC functionality. If so, could we split this into a separate commit?
This would make it clearer for the reader to distinguish between the
refactoring changes and the new changes related to enabling launch-time XDP
ZC support.
> static netdev_tx_t igc_xmit_frame_ring(struct sk_buff *skb,
> struct igc_ring *tx_ring)
> {
> @@ -1603,26 +1623,8 @@ static netdev_tx_t igc_xmit_frame_ring(struct sk_buff *skb,
> skb->tstamp = ktime_set(0, 0);
> launch_time = igc_tx_launchtime(tx_ring, txtime, &first_flag, &insert_empty);
>
> - if (insert_empty) {
> - struct igc_tx_buffer *empty_info;
> - struct sk_buff *empty;
> - void *data;
> -
> - empty_info = &tx_ring->tx_buffer_info[tx_ring->next_to_use];
> - empty = alloc_skb(IGC_EMPTY_FRAME_SIZE, GFP_ATOMIC);
> - if (!empty)
> - goto done;
> -
> - data = skb_put(empty, IGC_EMPTY_FRAME_SIZE);
> - memset(data, 0, IGC_EMPTY_FRAME_SIZE);
> -
> - igc_tx_ctxtdesc(tx_ring, 0, false, 0, 0, 0);
> -
> - if (igc_init_tx_empty_descriptor(tx_ring,
> - empty,
> - empty_info) < 0)
> - dev_kfree_skb_any(empty);
> - }
> + if (insert_empty)
> + igc_insert_empty_packet(tx_ring);
>
> done:
> /* record the location of the first descriptor for this packet */
> @@ -2955,9 +2957,33 @@ static u64 igc_xsk_fill_timestamp(void *_priv)
> return *(u64 *)_priv;
> }
>
> +static void igc_xsk_request_launch_time(u64 launch_time, void *_priv)
> +{
> + struct igc_metadata_request *meta_req = _priv;
> + struct igc_ring *tx_ring = meta_req->tx_ring;
> + __le32 launch_time_offset;
> + bool insert_empty = false;
> + bool first_flag = false;
> +
> + if (!tx_ring->launchtime_enable)
> + return;
> +
> + launch_time_offset = igc_tx_launchtime(tx_ring,
> + ns_to_ktime(launch_time),
> + &first_flag, &insert_empty);
> + if (insert_empty) {
> + igc_insert_empty_packet(tx_ring);
> + meta_req->tx_buffer =
> + &tx_ring->tx_buffer_info[tx_ring->next_to_use];
> + }
> +
> + igc_tx_ctxtdesc(tx_ring, launch_time_offset, first_flag, 0, 0, 0);
> +}
> +
> const struct xsk_tx_metadata_ops igc_xsk_tx_metadata_ops = {
> .tmo_request_timestamp = igc_xsk_request_timestamp,
> .tmo_fill_timestamp = igc_xsk_fill_timestamp,
> + .tmo_request_launch_time = igc_xsk_request_launch_time,
> };
>
> static void igc_xdp_xmit_zc(struct igc_ring *ring)
> @@ -2980,7 +3006,7 @@ static void igc_xdp_xmit_zc(struct igc_ring *ring)
> ntu = ring->next_to_use;
> budget = igc_desc_unused(ring);
>
> - while (xsk_tx_peek_desc(pool, &xdp_desc) && budget--) {
> + while (xsk_tx_peek_desc(pool, &xdp_desc) && budget >= 4) {
Could we add some explanation on what & why the value "4" is used ?
next prev parent reply other threads:[~2025-01-20 6:26 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-16 15:53 [PATCH bpf-next v6 0/4] xsk: TX metadata Launch Time support Song Yoong Siang
2025-01-16 15:53 ` [Intel-wired-lan] " Song Yoong Siang
2025-01-16 15:53 ` [PATCH bpf-next v6 1/4] xsk: Add launch time hardware offload support to XDP Tx metadata Song Yoong Siang
2025-01-16 15:53 ` [Intel-wired-lan] " Song Yoong Siang
2025-01-16 15:53 ` [PATCH bpf-next v6 2/4] selftests/bpf: Add launch time request to xdp_hw_metadata Song Yoong Siang
2025-01-16 15:53 ` [Intel-wired-lan] " Song Yoong Siang
2025-01-23 19:48 ` Stanislav Fomichev
2025-01-23 19:48 ` [Intel-wired-lan] " Stanislav Fomichev
2025-01-16 15:53 ` [PATCH bpf-next v6 3/4] net: stmmac: Add launch time support to XDP ZC Song Yoong Siang
2025-01-16 15:53 ` [Intel-wired-lan] " Song Yoong Siang
2025-01-16 15:53 ` [PATCH bpf-next v6 4/4] igc: " Song Yoong Siang
2025-01-16 15:53 ` [Intel-wired-lan] " Song Yoong Siang
2025-01-20 6:25 ` Abdul Rahim, Faizal [this message]
2025-01-20 6:25 ` Abdul Rahim, Faizal
2025-01-20 7:24 ` Choong Yong Liang
2025-01-20 7:24 ` [Intel-wired-lan] " Choong Yong Liang
2025-01-20 10:08 ` Song, Yoong Siang
2025-01-20 10:08 ` [Intel-wired-lan] " Song, Yoong Siang
2025-01-20 10:06 ` Song, Yoong Siang
2025-01-20 10:06 ` [Intel-wired-lan] " Song, Yoong Siang
2025-01-23 15:40 ` Bouska, Zdenek
2025-01-23 15:40 ` [Intel-wired-lan] " Bouska, Zdenek
2025-01-23 16:41 ` Song, Yoong Siang
2025-01-23 16:41 ` [Intel-wired-lan] " Song, Yoong Siang
2025-01-23 17:24 ` Florian Bezdeka
2025-01-23 17:24 ` [Intel-wired-lan] " Florian Bezdeka
2025-01-23 19:49 ` Stanislav Fomichev
2025-01-23 19:49 ` [Intel-wired-lan] " Stanislav Fomichev
2025-01-24 11:45 ` [xdp-hints] " Toke Høiland-Jørgensen
2025-01-24 11:45 ` [Intel-wired-lan] " Toke Høiland-Jørgensen
2025-01-27 18:04 ` Jakub Kicinski
2025-01-27 18:04 ` [Intel-wired-lan] " Jakub Kicinski
2025-01-27 18:29 ` Florian Bezdeka
2025-01-27 18:29 ` [Intel-wired-lan] " Florian Bezdeka
2025-01-27 19:20 ` Jakub Kicinski
2025-01-27 19:20 ` [Intel-wired-lan] " Jakub Kicinski
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=84770113-2546-4035-8bd4-bf9cedcfb00f@linux.intel.com \
--to=faizal.abdul.rahim@linux.intel.com \
--cc=alexandre.torgue@foss.st.com \
--cc=almasrymina@google.com \
--cc=andrew+netdev@lunn.ch \
--cc=andrii@kernel.org \
--cc=anthony.l.nguyen@intel.com \
--cc=ast@kernel.org \
--cc=bjorn@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=corbet@lwn.net \
--cc=daniel@iogearbox.net \
--cc=danielj@nvidia.com \
--cc=davem@davemloft.net \
--cc=donald.hunter@gmail.com \
--cc=eddyz87@gmail.com \
--cc=edumazet@google.com \
--cc=florian.bezdeka@siemens.com \
--cc=haoluo@google.com \
--cc=hawk@kernel.org \
--cc=horms@kernel.org \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jdamato@fastly.com \
--cc=joabreu@synopsys.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=jonathan.lemon@gmail.com \
--cc=kpsingh@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=maciej.fijalkowski@intel.com \
--cc=magnus.karlsson@intel.com \
--cc=martin.lau@linux.dev \
--cc=mcoquelin.stm32@gmail.com \
--cc=mykolal@fb.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=przemyslaw.kitszel@intel.com \
--cc=sdf@fomichev.me \
--cc=shuah@kernel.org \
--cc=song@kernel.org \
--cc=willemb@google.com \
--cc=xdp-hints@xdp-project.net \
--cc=xuanzhuo@linux.alibaba.com \
--cc=yonghong.song@linux.dev \
--cc=yoong.siang.song@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.