[virtio-dev] Re: [virtio-comment] RE: [PATCH v13] virtio-net: support inner header hash

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Apr 26, 2023 at 02:24:48PM +0000, Parav Pandit wrote:
> 
> 
> > From: Heng Qi <hengqi@linux.alibaba.com>
> > Sent: Wednesday, April 26, 2023 10:04 AM
> 
> > Yes, but that seems like a tiny cost, and the cvq command-related structure is
> > much simpler.
> Current structure size is 24 bytes.
> This size becomes multiplier with device count scale to be always available and rarely changes.
> 
> As we add new features such device capabilities grow making the multiplier bigger.
> For example 
> a. flow steering capabilities (how many flows, what mask, supported protocols, generic options)
> b. hds capabilities
> c. counter capabilities (histogram based, which error counters supported, etc) 
> d. which new type of tx vq improvements supported.
> e. hw gro context count supported
> 
> May be more..

All these are ROM though. Can be shared between functions on a single
device, be it VFs or multifunction PF. Yea I heard you about
maybe making them programmable. For some cases where there is a
hardware resource associated with it, it makes sense.
Not in this case though, it's just another way to calculate hash.


> Depending on the container/VM size certain capabilities may change from device to device.
> Hence it is hard to deduplicate them at device level.
> 
> Therefore, ability to query them over a non_always_available transport is preferred choice from the device.
> 
> A driver may choose to cache it if its being frequently accessed or ask device when needed.
> Even when it's cached by driver, it is coming from the component that doesn’t have transport level timeouts associated with it.

well caching by driver is using up same amount of RAM, only with no
chance to 

-- 
MST


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org