On Fri, May 15, 2026 at 04:57:41AM -0400, Michael S. Tsirkin wrote:
On Fri, May 15, 2026 at 10:29:55AM +0200, Stefano Garzarella wrote:
On Thu, May 14, 2026 at 01:44:53PM -0400, Michael S. Tsirkin wrote:
> On Thu, May 14, 2026 at 06:45:00PM +0200, Stefano Garzarella wrote:
> > On Thu, 14 May 2026 at 17:16, Michael S. Tsirkin <[email protected]> wrote:
[...]
> > >
> > >
> > > And so the bag of hacks grows. I feel this is energy not well spent.
> > > Please, let us fix this properly *first*. And then worry about how to
> > > backport. Maybe it will not be so terrible to backport after all.
> > >
> >
> > TBH I don't think this is an hack, but an issue we should fix in any case.
> > Regarding the second patch, I see your point, but it's a big change
> > that worries me. I'd like some more time to fix it properly without
> > rushing. Staying calm without realizing that userspace is broken like
> > we are now without this series :-(
> >
> > That said, evaluating further, I think we have a similar issue also
> > with STREAM on the host side where the skb usually doesn't free space,
> > so we need a merge strategy also there.
> >
> > So, I'd like to have time to fix both definitely. If you have time and
> > want to go ahead, please do.
> >
> > Thanks,
> > Stefano
>
> Well my patch was a start, we just need a strategy how to avoid copying
> everything, right?
Yep, and then there's the question of how to handle EOM without a payload,
but I think that's a special case. In theory, we don't support sending it,
but I'm not sure if POSIX allows it or not.
It seems to, but given we didn't allow it in the past, we probably
should not start now without a good solution.
Agree.
Really we should add a feature bit for EOM to steal a byte from
buf_alloc. Or several bytes)
Yes, I agree. At this point, though, could we define a new protocol that
also takes overhead into account, or would it be too complicated to
synchronize both?
That said, is it okay if I send a v4 of this series?
(I'm not sure if I'll be able to work on the merging next week)
Stefano
I do worry we are piling up hacks and we'll end up with races
for all our troubles. That said, up to you.
I see it differently; Patch 1 should have been there from the start.
Patch 2, unless we completely remove the overhead, we should keep it, or
use it to trigger merging (e.g., when the overhead reaches a threshold
that depends on `buf_alloc`).
I prefer to send a v4.
Thanks,
Stefano
