From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Palagummi, Siva" <Siva.Palagummi@ca.com>
Cc: Jan Beulich <JBeulich@suse.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [PATCH RFC] xen/netback: Count ring slots properly when larger MTU sizes are used
Date: Wed, 22 Aug 2012 14:40:00 +0100 [thread overview]
Message-ID: <1345642800.12501.13.camel@zakaz.uk.xensource.com> (raw)
In-Reply-To: <7D7C26B1462EB14CB0E7246697A18C1311B4D9@INHYMS111B.ca.com>
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
-- 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.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2012-08-22 13:40 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-13 0:12 [PATCH RFC] xen/netback: Count ring slots properly when larger MTU sizes are used Palagummi, Siva
2012-08-13 8:27 ` Jan Beulich
2012-08-14 21:17 ` Palagummi, Siva
2012-08-21 13:14 ` Ian Campbell
2012-08-22 13:14 ` Palagummi, Siva
2012-08-22 13:22 ` Ian Campbell
2012-08-22 13:30 ` Palagummi, Siva
2012-08-22 13:40 ` Ian Campbell [this message]
2012-08-22 14:32 ` Palagummi, Siva
2012-08-22 14:39 ` Ian Campbell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1345642800.12501.13.camel@zakaz.uk.xensource.com \
--to=ian.campbell@citrix.com \
--cc=JBeulich@suse.com \
--cc=Siva.Palagummi@ca.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).