On 10/10, David Wei wrote: > On 2024-10-09 16:05, Pavel Begunkov wrote: > > On 10/9/24 17:30, Stanislav Fomichev wrote: > >> On 10/08, David Wei wrote: > >>> On 2024-10-08 08:58, Stanislav Fomichev wrote: > >>>> On 10/07, David Wei wrote: > >>>>> From: Pavel Begunkov <asml.silence@xxxxxxxxx> > >>>>> > >>>>> There are scenarios in which the zerocopy path might get a normal > >>>>> in-kernel buffer, it could be a mis-steered packet or simply the linear > >>>>> part of an skb. Another use case is to allow the driver to allocate > >>>>> kernel pages when it's out of zc buffers, which makes it more resilient > >>>>> to spikes in load and allow the user to choose the balance between the > >>>>> amount of memory provided and performance. > >>>> > >>>> Tangential: should there be some clear way for the users to discover that > >>>> (some counter of some entry on cq about copy fallback)? > >>>> > >>>> Or the expectation is that somebody will run bpftrace to diagnose > >>>> (supposedly) poor ZC performance when it falls back to copy? > >>> > >>> Yeah there definitely needs to be a way to notify the user that copy > >>> fallback happened. Right now I'm relying on bpftrace hooking into > >>> io_zcrx_copy_chunk(). Doing it per cqe (which is emitted per frag) is > >>> too much. I can think of two other options: > >>> > >>> 1. Send a final cqe at the end of a number of frag cqes with a count of > >>> the number of copies. > >>> 2. Register a secondary area just for handling copies. > >>> > >>> Other suggestions are also very welcome. > >> > >> SG, thanks. Up to you and Pavel on the mechanism and whether to follow > >> up separately. Maybe even move this fallback (this patch) into that separate > >> series as well? Will be easier to review/accept the rest. > > > > I think it's fine to leave it? It shouldn't be particularly > > interesting to the net folks to review, and without it any skb > > with the linear part would break it, but perhaps it's not such > > a concern for bnxt. > > > > My preference is to leave it. Actually from real workloads, fully > linearized skbs are not uncommon due to the minimum size for HDS to kick > in for bnxt. Taking this out would imo make this patchset functionally > broken. Since we're all in agreement here, let's defer the improvements > as a follow up. Sounds good!
