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

[Parav Pandit <parav@nvidia.com>]

> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Wednesday, April 26, 2023 10:58 AM

> 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.
Right. Some are, some are not ROM.
And it demands special circuitry for non-critical path.

> Not in this case though, it's just another way to calculate hash.
> 
Sure. Instead of doing field by field bi-section this way requires constant discussion like this.
Instead, placement of time critical fields in MMIO is better approach as it is generic guideline vs ROM/RAM fields.
 
> 
> > 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
> 
No chance to fault. And better utilizing the device.
And it is not always the pinned RAM, future it can be paged out too. 
Many fields won't be even cached.
Some may even get set in the net_device or other kernel level device structures.