[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z6NaFkPBZA18oILE@boxer>
Date: Wed, 5 Feb 2025 13:31:18 +0100
From: Maciej Fijalkowski <maciej.fijalkowski@...el.com>
To: Song Yoong Siang <yoong.siang.song@...el.com>
CC: "David S . Miller" <davem@...emloft.net>, Eric Dumazet
<edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni
<pabeni@...hat.com>, Simon Horman <horms@...nel.org>, Willem de Bruijn
<willemb@...gle.com>, Florian Bezdeka <florian.bezdeka@...mens.com>, "Donald
Hunter" <donald.hunter@...il.com>, Jonathan Corbet <corbet@....net>, "Bjorn
Topel" <bjorn@...nel.org>, Magnus Karlsson <magnus.karlsson@...el.com>,
Jonathan Lemon <jonathan.lemon@...il.com>, Andrew Lunn
<andrew+netdev@...n.ch>, Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann
<daniel@...earbox.net>, Jesper Dangaard Brouer <hawk@...nel.org>, "John
Fastabend" <john.fastabend@...il.com>, Joe Damato <jdamato@...tly.com>,
Stanislav Fomichev <sdf@...ichev.me>, Xuan Zhuo <xuanzhuo@...ux.alibaba.com>,
Mina Almasry <almasrymina@...gle.com>, Daniel Jurgens <danielj@...dia.com>,
Andrii Nakryiko <andrii@...nel.org>, Eduard Zingerman <eddyz87@...il.com>,
Mykola Lysenko <mykolal@...com>, Martin KaFai Lau <martin.lau@...ux.dev>,
Song Liu <song@...nel.org>, Yonghong Song <yonghong.song@...ux.dev>, KP Singh
<kpsingh@...nel.org>, Hao Luo <haoluo@...gle.com>, Jiri Olsa
<jolsa@...nel.org>, Shuah Khan <shuah@...nel.org>, Alexandre Torgue
<alexandre.torgue@...s.st.com>, Jose Abreu <joabreu@...opsys.com>, "Maxime
Coquelin" <mcoquelin.stm32@...il.com>, Tony Nguyen
<anthony.l.nguyen@...el.com>, Przemek Kitszel <przemyslaw.kitszel@...el.com>,
Faizal Rahim <faizal.abdul.rahim@...ux.intel.com>, Choong Yong Liang
<yong.liang.choong@...ux.intel.com>, Bouska Zdenek
<zdenek.bouska@...mens.com>, <netdev@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <linux-doc@...r.kernel.org>,
<bpf@...r.kernel.org>, <linux-kselftest@...r.kernel.org>,
<linux-stm32@...md-mailman.stormreply.com>,
<linux-arm-kernel@...ts.infradead.org>, <intel-wired-lan@...ts.osuosl.org>,
<xdp-hints@...-project.net>
Subject: Re: [PATCH bpf-next v8 4/5] igc: Refactor empty packet insertion
into a reusable function
On Wed, Feb 05, 2025 at 10:41:15AM +0800, Song Yoong Siang wrote:
> Refactor the code for inserting an empty packet into a new function
> igc_insert_empty_packet(). This change extracts the logic for inserting
> an empty packet from igc_xmit_frame_ring() into a separate function,
> allowing it to be reused in future implementations, such as the XDP
> zero copy transmit function.
>
> This patch introduces no functional changes.
>
> Signed-off-by: Song Yoong Siang <yoong.siang.song@...el.com>
Your SoB should be last in the set of tags.
> Reviewed-by: Faizal Rahim <faizal.abdul.rahim@...ux.intel.com>
> ---
> drivers/net/ethernet/intel/igc/igc_main.c | 42 ++++++++++++-----------
> 1 file changed, 22 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/igc/igc_main.c b/drivers/net/ethernet/intel/igc/igc_main.c
> index 21f318f12a8d..553d6d82af0d 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);
I still don't like the fact igc_insert_empty_packet() doesn't communicate
to caller whether it successfully produced descriptors or not.
Look at this from igc_xmit_frame_ring() POV:
- at the beginning you peek at Tx ring whether there is required amount of
descriptors free to be used
- but then here's your additional routine which might consume two more
descs and you are not aware of the status
- then you continue to further produce descriptors assuming there is
enough space in Tx ring
Right now igc_init_tx_empty_descriptor() returns -EBUSY when ring is full.
How can that happen in the first place + what if it would *really* happen
though? You just continue with your Tx flow.
What I'm trying to say here is, at least from correctness POV, you should
take into the account two potential descriptors for launchtime feature
when calling igc_maybe_stop_tx(). And igc_init_tx_empty_descriptor()
should not really care about space in ring, it should be a caller's job to
call it only when it will be sure it's safe to do so.
> +}
> +
> 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 */
> --
> 2.34.1
>
Powered by blists - more mailing lists