From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752300AbcIINlu (ORCPT ); Fri, 9 Sep 2016 09:41:50 -0400 Received: from smtp02.citrix.com ([66.165.176.63]:32597 "EHLO SMTP02.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751708AbcIINlr (ORCPT ); Fri, 9 Sep 2016 09:41:47 -0400 X-IronPort-AV: E=Sophos;i="5.30,305,1470700800"; d="scan'208";a="385377041" Subject: Re: [PATCH net-next] xen-netfront: avoid packet loss when ethernet header crosses page boundary To: Vitaly Kuznetsov , References: <1471880577-21380-1-git-send-email-vkuznets@redhat.com> CC: , , "Boris Ostrovsky" , Juergen Gross , Patrick Talbert From: David Vrabel Message-ID: <57D2BC13.8050903@citrix.com> Date: Fri, 9 Sep 2016 14:41:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.5.0 MIME-Version: 1.0 In-Reply-To: <1471880577-21380-1-git-send-email-vkuznets@redhat.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-DLP: MIA1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 22/08/16 16:42, Vitaly Kuznetsov wrote: > 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 We should probably fix the backend to handle this (by grant copying a minimum amount in the linear area, but since netfront needs to work with older netback. Acked-by: David Vrabel David