Re: [RFC v2 07/11] tap: support tx through vhost

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 2332 bytes --]

On Thu, Jul 24, 2025 at 04:30:50PM +0200, Stefano Brivio wrote:
> Silly comments only:
> 
> On Thu, 24 Jul 2025 10:24:39 +1000
> David Gibson <david@gibson.dropbear.id.au> wrote:
> 
> > On Wed, Jul 09, 2025 at 07:47:44PM +0200, Eugenio Pérez wrote:
> > > No users enable vhost right now, just defining the functions.
> > > 
> > > The use of virtqueue is similar than in rx case.  fills the descriptor
> > > table with packet data it wants to send to the namespace.  Each
> > > descriptor points to a buffer in memory, with an address and a length.
> > > The number of descriptors is again defined by VHOST_NDESCS.  
> > 
> > Does the number of descriptors have to be equal for the Tx and Rx
> > queues?  For Rx, the number of descriptors is basically determined by
> > how many frames we can fit in pkt_buf.  That doesn't really apply to
> > the Tx path though, it would be more natural to define the number of
> > Tx descriptors independently.
> > 
> > > Afterwards it writes the descriptor index into the avail->ring[] array,
> > > then increments avail->idx to make it visible to the kernel, then kicks
> > > the virtqueue 1 event fd.
> > > 
> > > When the kernel does not need the buffer anymore it writes its id into
> > > the used_ring->ring[], and increments used_ring->idx.  Normally, the
> > > kernel also notifies pasta through call eventfd of the virtqueue 1.
> > > But we don't monitor the eventfd.  Instead, we check if we can reuse the
> > > buffers or not just when we produce, making the code simpler and more
> > > performant.  
> > 
> > Oh, that's pretty neat.
> > 
> > Nit: s/performant/performent/
> 
> Actually, "performent" (which I had never heard before) seems to be an
> archaic term for "performance":
> 
>   https://www.oed.com/dictionary/performent_n
> 
> whereas "performant":
> 
>   https://en.wiktionary.org/wiki/performant

Oops, you're right.  Embarrassing.  "performant" looked wrong to
me... now they both do.

> seems to be fitting here (as much as I'd favour "efficient" instead,
> because it actually sounds like a real word ;)).

Yeah, agreed.

-- 
David Gibson (he or they)	| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you, not the other way
				| around.
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]