From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason Wang Subject: Re: [net-next rfc v7 1/3] virtio-net: separate fields of sending/receiving queue from virtnet_info Date: Mon, 03 Dec 2012 13:15:01 +0800 Message-ID: <3524590.ZWGua7A8ne@jason-thinkpad-t430s> References: <1354011360-39479-1-git-send-email-jasowang@redhat.com> <1354011360-39479-2-git-send-email-jasowang@redhat.com> <87y5hfj3vl.fsf@rustcorp.com.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1428408837302201728==" Cc: krkumar2@in.ibm.com, kvm@vger.kernel.org, mst@redhat.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, bhutchings@solarflare.com, jwhan@filewood.snu.ac.kr, shiyer@redhat.com To: Rusty Russell Return-path: In-Reply-To: <87y5hfj3vl.fsf@rustcorp.com.au> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: virtualization-bounces@lists.linux-foundation.org Errors-To: virtualization-bounces@lists.linux-foundation.org List-Id: netdev.vger.kernel.org This is a multi-part message in MIME format. --===============1428408837302201728== Content-Type: multipart/alternative; boundary="nextPart1430680.RAus0D4jCW" Content-Transfer-Encoding: 7Bit This is a multi-part message in MIME format. --nextPart1430680.RAus0D4jCW Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Monday, December 03, 2012 12:25:42 PM Rusty Russell wrote: > Jason Wang 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 --nextPart1430680.RAus0D4jCW Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="us-ascii"

On Monday, December 03, 2012 12:25:42 PM Rusty Russell wrote:

> Jason Wang <jasowang@redhat.com> 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

--nextPart1430680.RAus0D4jCW-- --===============1428408837302201728== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization --===============1428408837302201728==--