Linux Virtualization - Jan 2014 - [PATCH net-next v2 4/4] virtio-net: initial debugfs support, export mergeable rx buffer size

Sorry I missed this important piece of information, it appears that
netdev_queue (the TX equivalent of netdev_rx_queue) already has
decoupled itself from CONFIG_XPS due to an attribute,
queue_trans_timeout, that does not depend on XPS functionality. So it
seems that something somewhat equivalent has already happened on the
TX side.

Best,

Mike

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

On Tue, Jan 14, 2014 at 01:45:42PM -0800, Michael Dalton
wrote:
> 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
I'm guessing we should follow the bonding example.
What do others think?