[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH RFC] xen/netback: Count ring slots properly when larger MTU sizes are used



On Wed, 2012-08-22 at 15:32 +0100, Palagummi, Siva wrote:
> 
> > -----Original Message-----
> > From: Ian Campbell [mailto:Ian.Campbell@xxxxxxxxxx]
> > Sent: Wednesday, August 22, 2012 7:10 PM
> > To: Palagummi, Siva
> > Cc: Jan Beulich; xen-devel@xxxxxxxxxxxxx
> > Subject: Re: [Xen-devel] [PATCH RFC] xen/netback: Count ring slots
> > properly when larger MTU sizes are used
> > 
> > On Wed, 2012-08-22 at 14:30 +0100, Palagummi, Siva wrote:
> > > > >
> > > > >
> > > > > > This:
> > > > > >             /* Filled the batch queue? */
> > > > > >             if (count + MAX_SKB_FRAGS >= XEN_NETIF_RX_RING_SIZE)
> > > > > >                     break;
> > > > > > seems a bit iffy to me too. I wonder if MAX_SKB_FRAGS should be
> > > > > > max_required_rx_slots(vif)? Or maybe the preflight checks from
> > > > > > xenvif_start_xmit save us from this fate?
> > > > > >
> > > > > > Ian.
> > > > >
> > > > > You are right Ian. The intention of this check seems to be to
> > ensure
> > > > > that enough slots are still left prior to picking up next skb.
> > But
> > > > > instead of invoking max_required_rx_slots with already received
> > skb,
> > > > > we may have to do skb_peek and invoke max_required_rx_slots on
> > skb
> > > > > that we are about to dequeue. Is there any better way?
> > > >
> > > > max_required_rx_slots doesn't take an skb as an argument, just a
> > vif.
> > > > It
> > > > returns the worst case number of slots for any skb on that vif.
> > > >
> > > > Ian.
> > >
> > > Thatâs true. What I meant is to peek to next skb and get vif from
> > that
> > > structure to invoke max_required_rx_slots. Don't you think we need to
> > > do like that?
> > 
> > Do you mean something other than max_required_rx_slots? Because the
> > prototype of that function is
> >         static int max_required_rx_slots(struct xenvif *vif)
> > i.e. it doesn't need an skb.
> > 
> > I think it is acceptable to check for the worst case number of slots.
> > That's what we do e.g. in xen_netbk_rx_ring_full
> > 
> > Using skb_peek might work too though, assuming all the locking etc is
> > ok o
> 
> I want to use max_required_rx_slots only. So the code will look somewhat like 
> this.
> 
> skb=skb_peek(&netbk->rx_queue);
> if(skb == NULL)
>       break;
> vif=netdev_priv(skb->dev);

Oh, I see why you need the skb now!

> /*Filled the batch queue?*/
> If(count + max_required_rx_slots(vif) >= XEN_NETIF_RX_RING_SIZE)
>       break;

You need to to finally dequeue the skb here.

> 
> 
> > -- this is a private queue so I think it is probably ok. Rather than
> > calculating the number of slots in xen_netbk_rx_action you probably
> > want
> > to remember the value from the call to xen_netbk_count_skb_slots in
> > start_xmit. Perhaps by stashing it in skb->cb? (see NETFRONT_SKB_CB for
> > an example of how to do this)
> > 
> > Ian.
> 
> Ok. I will look into this as well. This will definitely save some
> cycles in xen_netbk_rx_action. Apart from that calculations we already
> discussed should work fine right?

I think so. Proof in the pudding and all that ;-)

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.