> > > @@ -3113,13 +3270,14 @@ static int virtnet_probe(struct virtio_device *vdev)
> > > u16 max_queue_pairs;
> > > int mtu;
> > >
> > > - /* Find if host supports multiqueue virtio_net device */
> > > - err = virtio_cread_feature(vdev, VIRTIO_NET_F_MQ,
> > > - struct virtio_net_config,
> > > - max_virtqueue_pairs, &max_queue_pairs);
> > > + /* Find if host supports multiqueue/rss virtio_net device */
> > > + max_queue_pairs = 1;
> > > + if (virtio_has_feature(vdev, VIRTIO_NET_F_MQ) || virtio_has_feature(vdev, VIRTIO_NET_F_RSS))
> > > + max_queue_pairs =
> > > + virtio_cread16(vdev, offsetof(struct virtio_net_config, max_virtqueue_pairs));
> >
> > Instead of testing either feature and treating them as somewhat equal,
> > shouldn't RSS be dependent on MQ?
>
> No, RSS is dependent on CTRL_VQ. Technically RSS and MQ are similar features.
RSS depends on having multiple queues.
What would enabling VIRTIO_NET_F_RSS without VIRTIO_NET_F_MQ do?
> >
> > >
> > > /* We need at least 2 queue's */
> > > - if (err || max_queue_pairs < VIRTIO_NET_CTRL_MQ_VQ_PAIRS_MIN ||
> > > + if (max_queue_pairs < VIRTIO_NET_CTRL_MQ_VQ_PAIRS_MIN ||
> > > max_queue_pairs > VIRTIO_NET_CTRL_MQ_VQ_PAIRS_MAX ||
> > > !virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_VQ))
> > > max_queue_pairs = 1;
> > > @@ -3207,6 +3365,23 @@ static int virtnet_probe(struct virtio_device *vdev)
> > > if (virtio_has_feature(vdev, VIRTIO_NET_F_MRG_RXBUF))
> > > vi->mergeable_rx_bufs = true;
> > >
> > > + if (virtio_has_feature(vdev, VIRTIO_NET_F_RSS)) {
> > > + vi->has_rss = true;
> > > + vi->rss_indir_table_size =
> > > + virtio_cread16(vdev, offsetof(struct virtio_net_config,
> > > + rss_max_indirection_table_length));
> > > + vi->rss_key_size =
> > > + virtio_cread8(vdev, offsetof(struct virtio_net_config, rss_max_key_size));
> > > +
> > > + vi->rss_hash_types_supported =
> > > + virtio_cread32(vdev, offsetof(struct virtio_net_config, supported_hash_types));
> > > + vi->rss_hash_types_supported &=
> > > + ~(VIRTIO_NET_RSS_HASH_TYPE_IP_EX |
> > > + VIRTIO_NET_RSS_HASH_TYPE_TCP_EX |
> > > + VIRTIO_NET_RSS_HASH_TYPE_UDP_EX);
> > > +
> > > + dev->hw_features |= NETIF_F_RXHASH;
> >
> > Only make the feature visible when the hash is actually reported in
> > the skb, patch 3.
>
> VirtioNET has two features: RSS(steering only) and hash(hash report in
> vnet header)
> Both features may be enabled/disabled separately:
> 1. rss on and hash off - packets steered to the corresponding vqs
> 2. rss off and hash on - packets steered by tap(like mq) but headers
> have properly calculated hash.
> 3. rss on and hash on - packets steered to corresponding vqs and hash
> is present in the header.
>
> RXHASH feature allows the user to enable/disable the rss/hash(any combination).
I find that confusing, but.. I see that there is prior art where some
drivers enable/disable entire RSS load balancing based on this flag.
So ok.
> I think it's a good idea to leave RXHASH in patch 2/4 to give the user
> ability to manipulate the rss only feature.
> But, if you think that it requires to move it to the 3/4, I'll do it.
>
> >
> > Also, clearly separate the feature patches (2) rss, (3) rxhash, (4)
> > rxhash config.
>
> Currently:
> Patch 2/4 - adds VirtioNet rss feature.
> Patch 3/4 - adds VirtioNet hash report feature.
> Patch 4/4 - adds the ability to manipulate supported hash types.
>
> Can you provide more detailed suggestions on how to move hunks?
I gave one in the follow-on patch, to which you responded. That's probably it.
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
