# Re: \[net-next rfc v7 1/3\] virtio-net: separate fields of sending/receiving queue from virtnet\_info

- From: Jason Wang \<hidden\>
- Date: 2012-12-03 05:15:01 
- List: netdev
- Page: https://ratatoskr.run/netdev/2012/12/10909731
- Thread: https://ratatoskr.run/kvm/2012/11/3963825/t.md

```text
On Monday, December 03, 2012 12:25:42 PM Rusty Russell wrote:
> Jason Wang [ref] writes:
> > To support multiqueue transmitq/receiveq, the first step is to separate
> > queue related structure from virtnet_info. This patch introduce
> > send_queue and receive_queue structure and use the pointer to them as the
> > parameter in functions handling sending/receiving.
> 
> OK, seems like a straightforward xform: a few nit-picks:
> > +/* Internal representation of a receive virtqueue */
> > +struct receive_queue {
> > +	/* Virtqueue associated with this receive_queue */
> > +	struct virtqueue *vq;
> > +
> > +        struct napi_struct napi;
> > +
> > +        /* Number of input buffers, and max we've ever had. */
> > +        unsigned int num, max;
> 
> Weird whitespace here.
> 

Oh, yes, will fix it.
> > +
> > +	/* Work struct for refilling if we run low on memory. */
> > +	struct delayed_work refill;
> 
> I can't really see the justificaiton for a refill per queue.  Just have
> one work iterate all the queues if it happens, unless it happens often
> (in which case, we need to look harder at this anyway).

But during this kind of iteration, we may need enable/disable the napi 
regardless of whether the receive queue has lots to be refilled. This may add 
extra latency. 
> 
> >  struct virtnet_info {
> >  
> >  	struct virtio_device *vdev;
> > 
> > -	struct virtqueue *rvq, *svq, *cvq;
> > +	struct virtqueue *cvq;
> > 
> >  	struct net_device *dev;
> >  	struct napi_struct napi;
> 
> You leave napi here, and take it away in the next patch.  I think it's
> supposed to go away now.

Yes, will remove it.

Thanks
> 
> Cheers,
> Rusty.
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
```