From: Jason Wang <jasowang@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Vlad Yasevich <vyasevic@redhat.com>
Subject: Re: [PATCH net] macvtap: unbreak receiving of gro skb with frag list
Date: Wed, 28 Oct 2015 10:51:17 +0800 [thread overview]
Message-ID: <56303825.6070307@redhat.com> (raw)
In-Reply-To: <20151027110253-mutt-send-email-mst@redhat.com>
On 10/27/2015 05:05 PM, Michael S. Tsirkin wrote:
> On Tue, Oct 27, 2015 at 10:58:25AM +0800, Jason Wang wrote:
>>
>> On 10/26/2015 04:30 PM, Michael S. Tsirkin wrote:
>>> On Mon, Oct 26, 2015 at 02:53:38PM +0800, Jason Wang wrote:
>>>> On 10/26/2015 02:09 PM, Michael S. Tsirkin wrote:
>>>>> On Mon, Oct 26, 2015 at 11:15:57AM +0800, Jason Wang wrote:
>>>>>> On 10/23/2015 09:37 PM, Michael S. Tsirkin wrote:
>>>>>>> On Fri, Oct 23, 2015 at 12:57:05AM -0400, Jason Wang wrote:
>>>>>>>> We don't have fraglist support in TAP_FEATURES. This will lead
>>>>>>>> software segmentation of gro skb with frag list. Fixes by having
>>>>>>>> frag list support in TAP_FEATURES.
>>>>>>>>
>>>>>>>> With this patch single session of netperf receiving were restored from
>>>>>>>> about 5Gb/s to about 12Gb/s on mlx4.
>>>>>>>>
>>>>>>>> Fixes a567dd6252 ("macvtap: simplify usage of tap_features")
>>>>>>>> Cc: Vlad Yasevich <vyasevic@redhat.com>
>>>>>>>> Cc: Michael S. Tsirkin <mst@redhat.com>
>>>>>>>> Signed-off-by: Jason Wang <jasowang@redhat.com>
>>>>>>> Thanks!
>>>>>>> Does this mean we should look at re-adding NETIF_F_FRAGLIST
>>>>>>> to virtio-net as well?
>>>>>> Not sure I get the point, but probably not. This is for receiving and
>>>>>> skb_copy_datagram_iter() can deal with frag list.
>>>>> Point is:
>>>>> - bridge within guest
>>>>> - assigned device creating gro skbs with frag list bridged to virtio
>>>> I see, but this problem looks not specific to virtio. Most cards does
>>>> not support frag list.
>>> These will be slower when used with a bridge then, won't they?
>> For forwarding, not sure. GRO has latency and cpu overhead anyway.
> Right but that's up to the user. You aren't disabling GRO
> on source, you are just splitting it up.
>
>> Anyway I can try to add the support for this.
> Which reminds me: on modern devices there are commands to control
> offloads, so for these, we should support turning offloads on/off using
> ethtool.
>
Trying to implement frag list but see a problem. Looks like driver need
to scan the possible number of io vectors? (Since vhost support max to
UIO_MAXIOV number of io vectors). Looks like there's no clarification on
this in the spec. (Which only limit the length of descriptor chain to
Queue size).
prev parent reply other threads:[~2015-10-28 2:51 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-23 4:57 [PATCH net] macvtap: unbreak receiving of gro skb with frag list Jason Wang
2015-10-23 9:35 ` David Miller
2015-10-23 13:37 ` Michael S. Tsirkin
2015-10-26 3:15 ` Jason Wang
2015-10-26 6:09 ` Michael S. Tsirkin
2015-10-26 6:53 ` Jason Wang
2015-10-26 8:30 ` Michael S. Tsirkin
2015-10-27 2:58 ` Jason Wang
2015-10-27 9:05 ` Michael S. Tsirkin
2015-10-28 2:51 ` Jason Wang [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=56303825.6070307@redhat.com \
--to=jasowang@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=vyasevic@redhat.com \
/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).