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