From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932790AbcILLw0 (ORCPT ); Mon, 12 Sep 2016 07:52:26 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42580 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756103AbcILLwV (ORCPT ); Mon, 12 Sep 2016 07:52:21 -0400 From: Vitaly Kuznetsov To: David Miller Cc: , , , "Boris Ostrovsky" , Juergen Gross , Patrick Talbert , David Vrabel Subject: Re: [PATCH net-next] xen-netfront: avoid packet loss when ethernet header crosses page boundary References: <1471880577-21380-1-git-send-email-vkuznets@redhat.com> <57D2BC13.8050903@citrix.com> Date: Mon, 12 Sep 2016 13:52:17 +0200 In-Reply-To: <57D2BC13.8050903@citrix.com> (David Vrabel's message of "Fri, 9 Sep 2016 14:41:39 +0100") Message-ID: <87sht59vym.fsf@vitty.brq.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Mon, 12 Sep 2016 11:52:21 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org David Vrabel writes: > 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, could you please pick this up for net-next or are there any concerns remaining? Thanks, -- Vitaly