From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752720AbcITImV (ORCPT ); Tue, 20 Sep 2016 04:42:21 -0400 Received: from shards.monkeyblade.net ([184.105.139.130]:45158 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751387AbcITImS (ORCPT ); Tue, 20 Sep 2016 04:42:18 -0400 Date: Tue, 20 Sep 2016 04:41:19 -0400 (EDT) Message-Id: <20160920.044119.403211498498787643.davem@davemloft.net> To: vkuznets@redhat.com Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, ptalbert@redhat.com, boris.ostrovsky@oracle.com, david.vrabel@citrix.com, jgross@suse.com, xen-devel@lists.xenproject.org Subject: Re: [PATCH net-next v3] xen-netfront: avoid packet loss when ethernet header crosses page boundary From: David Miller In-Reply-To: <1474282420-9723-1-git-send-email-vkuznets@redhat.com> References: <1474282420-9723-1-git-send-email-vkuznets@redhat.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Tue, 20 Sep 2016 01:41:22 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Vitaly Kuznetsov Date: Mon, 19 Sep 2016 12:53:40 +0200 > Small packet loss is reported on complex multi host network configurations > including tunnels, NAT, ... My investigation led me to the following check > in netback which drops packets: > > if (unlikely(txreq.size < ETH_HLEN)) { > netdev_err(queue->vif->dev, > "Bad packet size: %d\n", txreq.size); > xenvif_tx_err(queue, &txreq, extra_count, idx); > break; > } > > But this check itself is legitimate. SKBs consist of a linear part (which > has to have the ethernet header) and (optionally) a number of frags. > Netfront transmits the head of the linear part up to the page boundary > as the first request and all the rest becomes frags so when we're > reconstructing the SKB in netback we can't distinguish between original > frags and the 'tail' of the linear part. The first SKB needs to be at > least ETH_HLEN size. So in case we have an SKB with its linear part > starting too close to the page boundary the packet is lost. > > I see two ways to fix the issue: > - Change the 'wire' protocol between netfront and netback to start keeping > the original SKB structure. We'll have to add a flag indicating the fact > that the particular request is a part of the original linear part and not > a frag. We'll need to know the length of the linear part to pre-allocate > memory. > - Avoid transmitting SKBs with linear parts starting too close to the page > boundary. That seems preferable short-term and shouldn't bring > significant performance degradation as such packets are rare. That's what > this patch is trying to achieve with skb_copy(). > > Signed-off-by: Vitaly Kuznetsov > Acked-by: David Vrabel Applied.