From: Shirley Ma <mashirle@us.ibm.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
Avi Kivity <avi@redhat.com>,
netdev@vger.kernel.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org,
Hollis Blanchard <hollisb@us.ibm.com>
Subject: Re: [PATCH 1/1] Defer skb allocation for both mergeable buffers and big packets in virtio_net
Date: Mon, 23 Nov 2009 15:27:15 -0800 [thread overview]
Message-ID: <1259018835.5022.64.camel@localhost.localdomain> (raw)
In-Reply-To: <200911240854.24054.rusty@rustcorp.com.au>
On Tue, 2009-11-24 at 08:54 +1030, Rusty Russell wrote:
> #define BIG_PACKET_PAD (NET_SKB_PAD - sizeof(struct virtio_net_hdr) +
> NET_IP_ALIGN)
> struct big_packet_page {
> struct virtio_net_hdr hdr;
> char pad[BIG_PACKET_PAD];
> /* Actual packet data starts here */
> unsigned char data[PAGE_SIZE - BIG_PACKET_PAD - sizeof(struct
> virtio_net_hdr)];
> };
The padding was used for qemu userspace buffer copy, skb data is copied
from the page for size of GOOD_COPY_LEN, and skb data is reserved
NET_IP_ALIGN.
If we add paddings as above, userspace copy will starts NET_SKB_PAD +
NET_IP_ALIGN? I am little bit confused here.
> Then use this type as the template for registering the sg list for the
> big packet case.
>
> > > I think you can move the memcpy outside the if, like so:
> > >
> > > memcpy(&hdr, p, hdr_len);
> >
> > I didn't move it out, because num_buf = hdr->mhdr.num_buffers;
>
> Yes, that has to stay inside, but the memcpy can move out. It's just
> a bit
> neater to have more common code.
num_buf is assigned after memcpy so we couldn't move memcpy out.
Anyway I separated mergeable buffers and big packets in the new patch to
make it clear and it will be easy to modify when we drop big packets
support in the future.
Thanks
Shirley
next prev parent reply other threads:[~2009-11-23 23:27 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-20 6:15 [PATCH 1/1] Defer skb allocation for both mergeable buffers and big packets in virtio_net Shirley Ma
2009-11-20 6:19 ` Eric Dumazet
2009-11-20 16:08 ` Shirley Ma
2009-11-20 16:21 ` Shirley Ma
2009-11-23 1:08 ` Rusty Russell
2009-11-23 16:07 ` Shirley Ma
2009-11-23 22:24 ` Rusty Russell
2009-11-23 23:27 ` Shirley Ma [this message]
2009-11-24 11:37 ` Michael S. Tsirkin
2009-11-24 14:36 ` Anthony Liguori
2009-11-24 16:04 ` Michael S. Tsirkin
2009-11-24 16:04 ` Michael S. Tsirkin
2009-11-25 0:15 ` Rusty Russell
2009-11-25 0:12 ` Rusty Russell
2009-11-25 9:15 ` Michael S. Tsirkin
2009-11-25 10:20 ` Rusty Russell
2009-11-25 11:40 ` Michael S. Tsirkin
2009-11-23 19:01 ` Shirley Ma
2009-11-23 9:43 ` Michael S. Tsirkin
2009-11-23 16:18 ` 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=1259018835.5022.64.camel@localhost.localdomain \
--to=mashirle@us.ibm.com \
--cc=avi@redhat.com \
--cc=eric.dumazet@gmail.com \
--cc=hollisb@us.ibm.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;
as well as URLs for NNTP newsgroup(s).