On Tue, 06 Dec 2022 19:47:13 -0800 Kees Cook wrote: > >Aammgh. build_skb(0) is plain silly, AFAIK. The performance hit of > >using kmalloc()'ed heads is large because GRO can't free the metadata. > >So we end up carrying per-MTU skbs across to the application and then > >freeing them one by one. With pages we just aggregate up to 64k of data > >in a single skb. > > This isn't changed by this patch, though? The users of > kmalloc+build_skb are pre-existing. Yes. > >I can only grep out 3 cases of build_skb(.. 0), could we instead > >convert them into a new build_skb_slab(), and handle all the silliness > >in such a new helper? That'd be a win both for the memory safety and one > >fewer branch for the fast path. > > When I went through callers, it was many more than 3. Regardless, I > don't see the point: my patch has no more branches than the original > code (in fact, it may actually be faster because I made the initial > assignment unconditional, and zero-test-after-assign is almost free, > where as before it tested before the assign. And now it's marked as > unlikely to keep it out-of-line. Maybe. > >I think it's worth doing, so LMK if you're okay to do this extra > >work, otherwise I can help (unless e.g. Eric tells me I'm wrong..). > > I had been changing callers to round up (e.g. bnx2), but it seemed > like centralizing this makes more sense. I don't think a different > helper will clean this up. It's a combination of the fact that I think "0 is magic" falls in the "garbage" category of APIs, and the fact that driver developers have many things to worry about, so they often don't know that using slab is a bad idea. So I want a helper out of the normal path, where I can put a kdoc warning that says "if you're doing this - GRO will suck, use page frags".
