[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250528171830.5968d18d@kernel.org>
Date: Wed, 28 May 2025 17:18:30 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Alexander Lobakin <aleksander.lobakin@...el.com>
Cc: Tony Nguyen <anthony.l.nguyen@...el.com>, <davem@...emloft.net>,
<pabeni@...hat.com>, <edumazet@...gle.com>, <andrew+netdev@...n.ch>,
<netdev@...r.kernel.org>, <maciej.fijalkowski@...el.com>,
<magnus.karlsson@...el.com>, <michal.kubiak@...el.com>,
<przemyslaw.kitszel@...el.com>, <ast@...nel.org>, <daniel@...earbox.net>,
<hawk@...nel.org>, <john.fastabend@...il.com>, <horms@...nel.org>,
<bpf@...r.kernel.org>
Subject: Re: [PATCH net-next 03/16] libeth: xdp: add XDP_TX buffers sending
On Wed, 28 May 2025 16:57:15 +0200 Alexander Lobakin wrote:
> > On Tue, 20 May 2025 13:59:04 -0700 Tony Nguyen wrote:
> >> + if (sinfo || !netmem_is_net_iov(netmem)) {
> >> + const struct page_pool *pp = __netmem_get_pp(netmem);
> >> +
> >> + dma_sync_single_for_device(pp->p.dev, desc.addr, desc.len,
> >> + DMA_BIDIRECTIONAL);
> >> + }
> >
> > How can we get an unreadable netmem into the XDP Tx path?
>
> For now, it's not allowed. This is future proof. I have plans to allow
> XDP and devmem to co-exist when the XDP program doesn't want to access
> frags, only headers. In that case, why forbid?
Nonsensical code is harder to maintain. Someone may need to refactor
this later and waste time trying to figure out why the condition is
there.
Plus in patch 1 you remove legit conditions to save branches and here
you seem to happily sprinkle dead code.
Powered by blists - more mailing lists