From: Shirley Ma <mashirle@us.ibm.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>,
Avi Kivity <avi@redhat.com>,
netdev@vger.kernel.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org,
Anthony Liguori <anthony@codemonkey.ws>
Subject: Re: PATCH v2 3/4] Defer skb allocation -- new recvbuf alloc & receive calls
Date: Mon, 14 Dec 2009 14:08:38 -0800 [thread overview]
Message-ID: <1260828518.8716.105.camel@localhost.localdomain> (raw)
In-Reply-To: <20091213114320.GC7074@redhat.com>
On Sun, 2009-12-13 at 13:43 +0200, Michael S. Tsirkin wrote:
> Interesting. I think skb_goodcopy will sometimes
> set *page to NULL. Will the above crash then?
Nope, when *page is NULL, *len is 0.
> don't put empty line here. if below is part of same logical block as
> skb_goodcopy.
Ok.
> Local variable shadows a parameter.
> It seems gcc will let you get away with a warning,
> but this is not legal C.
Ok.
> > +
> > + i = skb_shinfo(skb)->nr_frags;
> > + if (i >= MAX_SKB_FRAGS) {
> > + pr_debug("%s: packet too long %d\n",
> skb->dev->name,
> > + len);
>
> If this happens, we have corrupted memory already.
> We do need this check, but please put is before you increment
> nr_frags.
It is before increase for mergeable buffer case. Only one page(one frag)
per get_buf.
> > + skb->dev->stats.rx_length_errors++;
> > + return skb;
>
> This will propagate the error up the stack and corrupt
> more memory.
I just copied the code from original code. There might not be a problem
for mergeable buffer. I will double check.
> sizeof hdr->hdr
Ok.
> > +
> > + skb_to_sgvec(skb, sg+1, 0, skb->len);
>
> space around +
Ok.
> > +
> > + err = vi->rvq->vq_ops->add_buf(vi->rvq, sg, 0, 2, skb);
> > + if (err < 0)
> > + kfree_skb(skb);
> > + else
> > + skb_queue_head(&vi->recv, skb);
>
> So why are we queueing this still?
This is for small packet. I didn't change that code since it will
involve extra copy by using page.
> > +
> > + return err;
> > +}
> > +
> > +static int add_recvbuf_big(struct virtnet_info *vi, gfp_t gfp, bool
> *oom)
> > +{
> > + struct scatterlist sg[2 + MAX_SKB_FRAGS];
>
> MAX_SKB_FRAGS + 2 will be more readable.
> Also, create a macro for this constant and document
> why does +2 make sense?
One is for big packet virtio_net_hdr, one is for goodcopy skb.
> Again, pls explain *why* do we want 16 byte alignment.
> Also this code seems duplicated?
> Please put structs at top of file where they
> can be found.
Ok.
> > + };
> > +
> > + offset = sizeof(struct padded_vnet_hdr);
> > +
> > + for (i = total - 1; i > 0; i--) {
>
> I prefer --i.
Ok.
> Also, total is just a constant.
> So simply MAX_SKB_FRAGS + 1 will be clearer.
Ok.
> Why do we scan last to first?
> If there's reason, please add a comment.
We use page private to maintain next page, here there is no scan last to
first, just add the new page in list head instead of list tail, which
will require scan the list.
> space around - .
Ok.
> All the if (i == 1) handling on exit is really hard to grok.
> How about moving common code out of this loop
> into a function, and then you can
> for (i = total - 1; i > 1; i--) {
> handle(i);
> }
> handle(1);
> handle(0);
> add_buf
That works.
> do we really need *oom here and below?
> We can just set err to ENOMEM, no?
We could.
> Please do not return 0 on failure.
Ok.
next prev parent reply other threads:[~2009-12-14 22:09 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-20 6:09 [PATCH 0/1] Defer skb allocation for both mergeable buffers and big packets in virtio_net Shirley Ma
2009-11-23 0:53 ` Rusty Russell
2009-11-23 8:51 ` Mark McLoughlin
2009-12-08 12:21 ` Michael S. Tsirkin
2009-12-11 12:28 ` [PATCH v2 0/4] " Shirley Ma
2009-12-11 12:33 ` [PATCH v2 1/4] Defer skb allocation -- add destroy buffers function for virtio Shirley Ma
2009-12-13 10:26 ` Michael S. Tsirkin
2009-12-14 20:08 ` Shirley Ma
2009-12-14 20:22 ` Michael S. Tsirkin
2009-12-14 23:22 ` Shirley Ma
2009-12-15 10:57 ` Michael S. Tsirkin
2009-12-15 22:36 ` Rusty Russell
2009-12-15 22:40 ` Michael S. Tsirkin
2009-12-16 5:04 ` Rusty Russell
2009-12-14 3:25 ` Rusty Russell
2009-12-14 22:09 ` Shirley Ma
2009-12-11 12:43 ` [PATCH v2 2/4] Defer skb allocation -- new skb_set calls & chain pages in virtio_net Shirley Ma
2009-12-13 11:24 ` Michael S. Tsirkin
2009-12-14 21:23 ` Shirley Ma
2009-12-15 11:21 ` Michael S. Tsirkin
2009-12-14 6:54 ` Rusty Russell
2009-12-14 22:10 ` Shirley Ma
2009-12-11 12:46 ` PATCH v2 3/4] Defer skb allocation -- new recvbuf alloc & receive calls Shirley Ma
2009-12-13 11:43 ` Michael S. Tsirkin
2009-12-14 22:08 ` Shirley Ma [this message]
2009-12-15 0:37 ` Shirley Ma
2009-12-15 11:33 ` Michael S. Tsirkin
2009-12-15 16:25 ` Shirley Ma
2009-12-15 16:39 ` Michael S. Tsirkin
2009-12-15 18:42 ` [RFC PATCH] Subject: virtio: Add unused buffers detach from vring Shirley Ma
2009-12-15 18:47 ` Michael S. Tsirkin
2009-12-15 19:08 ` Shirley Ma
2009-12-15 19:14 ` Shirley Ma
2009-12-15 21:14 ` Michael S. Tsirkin
2009-12-11 12:49 ` [PATCH v2 4/4] Defer skb allocation -- change allocation & receiving in recv path Shirley Ma
2009-12-13 11:08 ` Michael S. Tsirkin
2009-12-15 8:43 ` Shirley Ma
2009-12-13 10:19 ` [PATCH v2 0/4] Defer skb allocation for both mergeable buffers and big packets in virtio_net Michael S. Tsirkin
2009-12-14 19:59 ` Shirley Ma
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=1260828518.8716.105.camel@localhost.localdomain \
--to=mashirle@us.ibm.com \
--cc=anthony@codemonkey.ws \
--cc=avi@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
/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