Subject: Re: [PATCH net] macvtap: unbreak receiving of gro skb with frag list

From: "Michael S. Tsirkin" <[email-masked]>
Date: Mon, 26 Oct 2015 08:09:31 +0200

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 <[email-masked]>
> >> Cc: Michael S. Tsirkin <[email-masked]>
> >> Signed-off-by: Jason Wang <[email-masked]>
> > 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

> >
> >> ---
> >>  drivers/net/macvtap.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
> >> index 248478c..197c939 100644
> >> --- a/drivers/net/macvtap.c
> >> +++ b/drivers/net/macvtap.c
> >> @@ -137,7 +137,7 @@ static const struct proto_ops macvtap_socket_ops;
> >>  #define TUN_OFFLOADS (NETIF_F_HW_CSUM | NETIF_F_TSO_ECN | NETIF_F_TSO | \
> >>  		      NETIF_F_TSO6 | NETIF_F_UFO)
> >>  #define RX_OFFLOADS (NETIF_F_GRO | NETIF_F_LRO)
> >> -#define TAP_FEATURES (NETIF_F_GSO | NETIF_F_SG)
> >> +#define TAP_FEATURES (NETIF_F_GSO | NETIF_F_SG | NETIF_F_FRAGLIST)
> >>  
> >>  static struct macvlan_dev *macvtap_get_vlan_rcu(const struct net_device *dev)
> >>  {
> >> -- 
> >> 1.8.3.1
> > --
> > To unsubscribe from this list: send the line "unsubscribe netdev" in
> > the body of a message to [email-masked]
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html