On Wed, Apr 26, 2023 at 02:24:48PM +0000, Parav Pandit wrote: > > > > From: Heng Qi <[email protected]> > > 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: [email protected] For additional commands, e-mail: [email protected]
