> From: Xuan Zhuo <[email protected]>
> Sent: Friday, August 4, 2023 11:49 AM
> So, you mean we will have many commands like:
>
> VIRTIO_ADMIN_CMD_NET_MAC_SET
> VIRTIO_ADMIN_CMD_NET_MTU_SET
> VIRTIO_ADMIN_CMD_NET_SPEED_SET
> VIRTIO_ADMIN_CMD_BLK_XXX1
> VIRTIO_ADMIN_CMD_BLK_XXX2
> .....
>
> Or a generic command with the offset and size of the field of the config
> space?
>
Mix of both. One command per field is too much.
Going forward we may not have single boxed config space as many of the config
is coming through the cvq logically separate per functionality.
Hence, command should be one per device type, that can set one or more
attributes of the device.
Attribute may be residing in the config space or otherwise.
VIRTIO_ADMIN_CMD_NET_SET
Input: bitmap (bit per field of config space or otherwise)
Input: field matches to bitmap
VIRTIO_ADMIN_CMD_BLK_SET
> > It should be through the flow filter queue so that it can be performant
> > like nic
> tx/rxq which has dedicated role.
>
> Why flow filter queue? I think the cvq is ok.
>
For any sensible use of the switch, beyond few filter commands needs a high
perf queue.
> In our case, the ip of the port is configured by the admin on the setup of the
> device.
>
> And that is configured to the switch. I think the flow filter is working
> inside the
> deivce.
>
I lost you on your last two points in terminology of admin, device etc.
We have
1. owner device
2. member device
3. Switch is typically on a owner device, having switch port for each member
device.
a. Owner device programs switch rules for ports.
b. Owner device also may program flow filter rules of its own for RQ for RSS
etc.
c. Member device programs follow filter rules of rss and more.
Flow filters are generic framework applies to all 3 use cases.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
