Messages in this thread | ![/](/images/icornerl.gif) | | Date | Wed, 5 Jul 2023 14:31:15 +0200 | Subject | Re: [PATCH RFC net-next 0/4] net: page_pool: a couple assorted optimizations | From | Alexander Lobakin <> |
| |
From: Jakub Kicinski <kuba@kernel.org> Date: Mon, 3 Jul 2023 11:57:34 -0700
> On Mon, 3 Jul 2023 15:50:55 +0200 Alexander Lobakin wrote: >>> The reason I did not do that is that I wasn't sure if there is no >>> weird (netcons?) case where skb gets freed from an IRQ :( >> >> Shouldn't they use dev_kfree_skb_any() or _irq()? Usage of plain >> kfree_skb() is not allowed in the TH :s > > I haven't looked at the code so I could be lying but I thought that > the only thing that can't run in hard IRQ context is the destructor, > so if the caller knows there's no destructor they can free the skb. > > I'd ask you the inverse question. If the main use case is skb xdp > (which eh, uh, okay..) then why not make it use napi_consume_skb()?
Remember about Wi-Fi, DSA, and other poor citizens with no native XDP! :D That was mostly a joke, but I thought of this, too. At the end my thought was "let's try making it cover more usecases" and I found this approach. I'm not saying it's optimal or even much needed, that's why I sent it to discuss basically.
(e.g. I wanted to try speed up xdp_return_frame{,_bulk}() using it)
> I don't think skb XDP can run in hard IRQ context, can it?
skb XDP can't happen in the TH and I think we could assume it's safe to use napi_consume_skb() there (with a fake non-zero budget :p).
> >> Anyway, if the flag really makes no sense, I can replace it with >> in_softirq(), it's my hobby to break weird drivers :D
Thanks, Olek
| ![\](/images/icornerr.gif) |