On Fri, May 08, 2026 at 05:58:06AM -0400, Michael S. Tsirkin wrote:
On Fri, May 08, 2026 at 11:41:21AM +0200, Stefano Garzarella wrote:
On Thu, May 07, 2026 at 06:48:47PM -0400, Michael S. Tsirkin wrote:
> On Thu, May 07, 2026 at 02:59:13PM +0200, Stefano Garzarella wrote:
> > On Thu, May 07, 2026 at 07:45:10AM -0400, Michael S. Tsirkin wrote:
> > > On Thu, May 07, 2026 at 11:09:47AM +0200, Stefano Garzarella wrote:
[...]
> > > > For now, we're already doing something:
> > > > merging the skuffs if they don't have EOM set.
> > >
> > >
> > > Right that's good. You could go further and merge with EOM too
> > > if you stick the info about message boundaries somewhere else.
> >
> > This adds a lot of complexity IMO, but we can try.
> >
> > Do you have something in mind?
>
> BER is clearly overkill but here's a POC that claude made for me,
> just to give u an idea. It's clearly has a ton of issues,
> for example I dislike how GFP_ATOMIC is handled.
Okay, I somewhat understand, but clearly this isn't net material
I doubt we have many other options given reverting the regression was
ruled out.
As Eric pointed out, we can't revert it.
so for now
I think the best thing to do is to merge the fixup I sent (or something
similar):
https://lore.kernel.org/netdev/[email protected]/
I reviewed that one, problem is it's a spec violation/change that we'll
have to support forever.
I have a few points to make on this, but let's discuss them there.
This is a major change that should be merged with more caution.
Could this have too much of an impact on performance?
Thanks,
Stefano
It's really a POC, real patch is left as an excersise for the reader
:).
eheh, I see, but honestly, this overcomplication scares me. I'll try to
think it over.
The correct approach IMHO is to only start using this
when we wasted a lot of memory on small packets.
For example, if sum(truesize) >= buf size.
then we'll not see a perf impact unless it's already pathological.
Agree on this, which is similar to what I'm doing in that patch.
Reducing the advertised buf_alloc only in pathological cases (e.g.
overhead > buf_alloc).
Stefano
