From: ebiederm@xmission.com (Eric W. Biederman)
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: David Miller <davem@davemloft.net>,
jasowang@redhat.com, eric.dumazet@gmail.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Basil Gor <basil.gor@gmail.com>
Subject: Re: [V2 PATCH 0/9] vhost/macvtap zeropcopy fixes
Date: Wed, 02 May 2012 14:54:37 -0700 [thread overview]
Message-ID: <87txzyb65e.fsf@xmission.com> (raw)
In-Reply-To: <20120502213128.GB8266@redhat.com> (Michael S. Tsirkin's message of "Thu, 3 May 2012 00:31:29 +0300")
"Michael S. Tsirkin" <mst@redhat.com> writes:
> On Wed, May 02, 2012 at 12:40:55PM -0700, Eric W. Biederman wrote:
>>
>> Side question. Are you aware that macvtap/vhost net is broken
>> in the presence of vlan accelleration and that vlan accelleration
>> is not optional if you are using vlan headers?
>>
>> Eric
>
> I didn't know. Could you explain please?
It is worth looking at the netdev history for some recent patches by
Basil Gor, as he has been hit by this issue and has been trying to come
up with a clean fix. I was burned by this issue in other parts of the
networking stack and so have been doing some basic review.
The short version is that on any normal path through the networking
stack we implement vlan header accelleration in hardware or emulation
in software. The result is that the ethernet vlan header is not
on the packet and is instead in the skb->tci field.
When coming on out the pf_packet sockets we don't include the vlan
header in the packet but instead the vlan header is put in aux data.
The result of all of this is that vhost/net.c looses the vlan
header when coming from pf_packet socket.
Furthermore macvtap_recvmsg does not act like pf_packet sockets
when there is a vlan header persent so weirdness ensues. Especially
when the packet is coming from a path where the vlan header has
been stripped and placed in skb->tci.
Eric
prev parent reply other threads:[~2012-05-02 21:54 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-02 3:41 [V2 PATCH 0/9] vhost/macvtap zeropcopy fixes Jason Wang
2012-05-02 3:41 ` [V2 PATCH 1/9] macvtap: zerocopy: fix offset calculation when building skb Jason Wang
2012-05-15 17:17 ` Shirley Ma
2012-05-02 3:41 ` [V2 PATCH 2/9] macvtap: zerocopy: fix truesize underestimation Jason Wang
2012-05-15 17:26 ` Shirley Ma
2012-05-16 3:04 ` Jason Wang
2012-05-16 15:03 ` Shirley Ma
2012-05-17 2:59 ` Jason Wang
2012-05-17 15:28 ` Shirley Ma
2012-05-18 10:10 ` Jason Wang
2012-05-18 15:22 ` Shirley Ma
2012-05-21 6:15 ` Jason Wang
2012-05-02 3:41 ` [V2 PATCH 3/9] macvtap: zerocopy: put page when fail to get all requested user pages Jason Wang
2012-05-15 17:33 ` Shirley Ma
2012-05-02 3:42 ` [V2 PATCH 4/9] macvtap: zerocopy: set SKBTX_DEV_ZEROCOPY only when skb is built successfully Jason Wang
2012-05-15 17:44 ` Shirley Ma
2012-05-16 3:17 ` Jason Wang
2012-05-02 3:42 ` [V2 PATCH 5/9] macvtap: zerocopy: validate vectors before building skb Jason Wang
2012-05-02 3:42 ` [V2 PATCH 6/9] vhost_net: zerocopy: fix possible NULL pointer dereference of vq->bufs Jason Wang
2012-05-02 3:42 ` [V2 PATCH 7/9] vhost_net: re-poll only on EAGAIN or ENOBUFS Jason Wang
2012-05-02 3:42 ` [V2 PATCH 8/9] vhost_net: zerocopy: adding and signalling immediately when fully copied Jason Wang
2012-05-02 3:42 ` [V2 PATCH 9/9] vhost: zerocopy: poll vq in zerocopy callback Jason Wang
2012-05-15 16:50 ` Shirley Ma
2012-05-16 2:58 ` Jason Wang
2012-05-16 15:10 ` Shirley Ma
2012-05-16 15:14 ` Michael S. Tsirkin
2012-05-16 17:32 ` Shirley Ma
2012-05-16 18:36 ` Michael S. Tsirkin
2012-05-16 19:08 ` Shirley Ma
2012-05-21 5:22 ` Jason Wang
2012-05-17 2:50 ` Jason Wang
2012-05-17 15:34 ` Shirley Ma
2012-05-18 9:58 ` Jason Wang
2012-05-18 15:29 ` Shirley Ma
2012-05-21 6:05 ` Jason Wang
2012-05-21 15:42 ` Shirley Ma
2012-05-21 16:12 ` Shirley Ma
2012-05-22 10:13 ` Jason Wang
2012-05-22 10:05 ` Jason Wang
2012-05-22 15:55 ` Shirley Ma
2012-05-23 10:31 ` Jason Wang
2012-05-02 5:50 ` [V2 PATCH 0/9] vhost/macvtap zeropcopy fixes Michael S. Tsirkin
2012-05-02 6:44 ` David Miller
2012-05-02 8:11 ` Michael S. Tsirkin
2012-05-02 19:40 ` Eric W. Biederman
2012-05-02 21:31 ` Michael S. Tsirkin
2012-05-02 21:54 ` Eric W. Biederman [this message]
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=87txzyb65e.fsf@xmission.com \
--to=ebiederm@xmission.com \
--cc=basil.gor@gmail.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=jasowang@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.