I'd like to confirm the preferred sysfs path structure for mergeable
receive buffers. Is 'mergeable_rx_buffer_size' the right attribute name
to use or is there a strong preference for a different name?
I believe the current approach proposed for the next patchset is to use a
per-netdev attribute group which we will add to the receive
queue kobj (struct netdev_rx_queue). That leaves us with at
least two options:
(1) Name the attribute group something, e.g., 'virtio-net', in which
case all virtio-net attributes for eth0 queue N will be of
the form:
/sys/class/net/eth0/queues/rx-N/virtio-net/<attribute name>
(2) Do not name the attribute group (leave the name NULL), in which
case AFAICT virtio-net and device-independent attributes would be
mixed without any indication. For example, all virtio-net
attributes for netdev eth0 queue N would be of the form:
/sys/class/net/eth0/queues/rx-N/<attribute name>
FWIW, the bonding netdev has a similar sysfs issue and uses a per-netdev
attribute group (stored in the 'sysfs_groups' field of struct netdevice)
In the case of bonding, the attribute group is named, so
device-independent netdev attributes are found in
/sys/class/net/eth0/<attribute name> while bonding attributes are placed
in /sys/class/net/eth0/bonding/<attribute name>.
So it seems like there is some precedent for using an attribute group
name corresponding to the driver name. Does using an attribute group
name of 'virtio-net' sound good or would an empty or different attribute
group name be preferred?
Best,
Mike
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
