From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9CC88C433E0 for ; Thu, 11 Mar 2021 10:23:25 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0472064DEE for ; Thu, 11 Mar 2021 10:23:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0472064DEE Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:48504 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lKITT-0003br-TO for qemu-devel@archiver.kernel.org; Thu, 11 Mar 2021 05:23:23 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:43056) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lKISb-00030K-V6 for qemu-devel@nongnu.org; Thu, 11 Mar 2021 05:22:29 -0500 Received: from mail-ed1-x534.google.com ([2a00:1450:4864:20::534]:39836) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lKISa-00073d-4Z for qemu-devel@nongnu.org; Thu, 11 Mar 2021 05:22:29 -0500 Received: by mail-ed1-x534.google.com with SMTP id bf3so1938587edb.6 for ; Thu, 11 Mar 2021 02:22:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EDlZIFc5Aw3ddoZcVJQW9e/PTEnQji8LVAOTTiSjRbU=; b=X995OYH/juizriNEYzBGeY2IVB9Ssl2yhowc87EjlMPgaigdIVJlGJ9BwDVs2RSWFU cNZ4f5YkAehiPbN5iCOkBDhuo1uUMMg04u/HnpqV/Bszw4ZHD0TE0EtU/G7345J5V2yP 9esFAEj8SI6QYNl0C0M84zs1UkkIfGG0AgZrNvBU5R6LO2dGy51t/msKHgGbC0yBDT4p EroRvKCpJH/aUEEsOT1ArOHtSyJ5kJPfgFRPO1k4OK4nmejcHDQg9IArjouiNT6/Sslj GX4Y/fLku/ujdTw0Nr6uXV0YQ+QglCC/7RGaM03pWinJD24C8tL0CaBysnemQUP/OrCo jssA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EDlZIFc5Aw3ddoZcVJQW9e/PTEnQji8LVAOTTiSjRbU=; b=fiP9dndd381GtSBPqTHpgNbZORH9YpUhQa/LGNwE6EjqhiydQsQEm2OyJ+xe+m58jA XD9IFYSkeTY/lZjkhEd7dwGB729uCiDwJ9MSaF1nJcSdn7ZSAfjywasawOhUcnJFH2uP dH5nQ2TR74FixY/SfgrQhl930sey6PfhQMDjcfhecC8HaNbM+Xva4br/HL7gRWkzIv+k wh+AEoJ3lZlaYK8rUvU7LV5g2LdCewQy2oObmA9fVO+9eMnNMoDVZndDinXYTxL/1O70 3tgzdOmuSABKANWlSY53KKZZeO8Zer0T6TUh8fZzf3mNxdlPhelmSeIsMAx6RmdBPOrT j2CQ== X-Gm-Message-State: AOAM5313GVSzWKZojfKyfh7P2quzvM6Rdhg33QQRxS9cJw/ba0WDrVuN Czv4lBtklNFSlErt4wuxRKeK/rmKnPuITu2vUPC9Gw== X-Google-Smtp-Source: ABdhPJwkkftzz8nrkVU2zE4ep5HPZenzuTY1ffpS2lexiY4I2HT4IfQgq9GcgbjS2/3CmcVSEcOYavZ2iPWVvcssajQ= X-Received: by 2002:a05:6402:c:: with SMTP id d12mr7666524edu.100.1615458146457; Thu, 11 Mar 2021 02:22:26 -0800 (PST) MIME-Version: 1.0 References: <20210303191205.1656980-1-philmd@redhat.com> <20210303191205.1656980-3-philmd@redhat.com> <36123f35-06ab-d0da-37d2-6f8324e7f582@redhat.com> In-Reply-To: From: Peter Maydell Date: Thu, 11 Mar 2021 10:22:07 +0000 Message-ID: Subject: Re: [RFC PATCH v3 02/10] net: Pad short frames to minimum size before send from SLiRP/TAP To: Bin Meng Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2a00:1450:4864:20::534; envelope-from=peter.maydell@linaro.org; helo=mail-ed1-x534.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Dmitry Fleytman , "Michael S. Tsirkin" , Jason Wang , Bin Meng , Richard Henderson , QEMU Developers , Stefan Hajnoczi , "Edgar E. Iglesias" , =?UTF-8?Q?Philippe_Mathieu=2DDaud=C3=A9?= Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Thu, 11 Mar 2021 at 09:58, Bin Meng wrote: > > On Thu, Mar 11, 2021 at 5:43 PM Peter Maydell wrote: > > > > On Thu, 11 Mar 2021 at 03:01, Jason Wang wrote: > > > And after a discussion 10 years ago [1]. Michael (cced) seems to want to > > > keep the padding logic in the NIC itself (probably with a generic helper > > > in the core). Since 1) the padding is only required for ethernet 2) > > > virito-net doesn't need that (it can pass incomplete packet by design). > > > > Like I said, we need to decide; either: > > > > (1) we do want to support short packets in the net core: > > every sender needs to either pad, or to have some flag to say > > "my implementation can't pad, please can the net core do it for me", > > unless they are deliberately sending a short packet. Every > > receiver needs to be able to cope with short packets, at least > > in the sense of not crashing (they should report them as a rx > > error if they have that kind of error reporting status register). > > I think we have mostly implemented our NIC models this way. > > > > (2) we simply don't support short packets in the net core: > > nobody (not NICs, not network backends) needs to pad, because > > they can rely on the core to do it. Some existing senders and > > receivers may have now-dead code to do their own padding which > > could be removed. > > > > MST is advocating for (1) in that old thread. That's a coherent > > position. > > But it's a wrong approach. As Edgar and Stefan also said in the old > discussion thread, padding in the RX is wrong as real world NICs don't > do this. Neither option (1) nor option (2) involve padding in RX. Option (1) is: * no NIC implementation pads on TX, except as defined by whatever NIC-specific config registers or h/w behaviour might require (ie if the guest wants to send a short packet it can do that) * non-NIC sources like slirp need to pad on TX unless they're deliberately trying to send a short packet * all receivers of packets need to cope with being given a short packet; this is usually going to mean "flag it to the guest as an RX error", but exact behaviour is NIC-dependent Option (2) is: * the net core code pads any packet that goes through it * no NIC implementation needs to pad on TX (it is harmless if they do) * non-NIC sources don't need to pad on TX * no receivers of packets need to cope with being given short packets Option 1 is what the real world does. Option 2 is a simplification which throws away the ability to emulate handling of short packets, in exchange for not having to sort out senders like slirp and not having to be so careful about short-packet handling in NIC models. If MST is correct that some use cases require short-packet support, then we need to go for option 1, I think. thanks -- PMM