[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


  • To: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
  • From: "Palagummi, Siva" <Siva.Palagummi@xxxxxx>
  • Date: Wed, 22 Aug 2012 14:32:32 +0000
  • Accept-language: en-US
  • Cc: Jan Beulich <JBeulich@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxx>
  • Delivery-date: Wed, 22 Aug 2012 14:33:06 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>
  • Thread-index: Ac146Cc2rIyVmg4PT4CbrdsCnnwOsQAF0kYAAFVDoZABRxX9AAAzUKyA///51oD//6PjEIAAYSAA//+jGZA=
  • Thread-topic: [Xen-devel] [PATCH RFC] xen/netback: Count ring slots properly when larger MTU sizes are used


> -----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);

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


> -- 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?

Thanks for all your input Ian.

Siva

_______________________________________________
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®.