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=-7.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 B8555C433DB for ; Thu, 11 Mar 2021 03:36:11 +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 3554464E22 for ; Thu, 11 Mar 2021 03:36:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3554464E22 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:33436 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lKC7O-0005Pw-33 for qemu-devel@archiver.kernel.org; Wed, 10 Mar 2021 22:36:10 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:34856) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lKC6V-0004uG-7a for qemu-devel@nongnu.org; Wed, 10 Mar 2021 22:35:15 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:22782) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1) (envelope-from ) id 1lKC5K-0007WH-Bj for qemu-devel@nongnu.org; Wed, 10 Mar 2021 22:35:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1615433640; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=U6KrSltbnetG5K66cM2kyRNpIeQIE+vlOqtXyl78rAI=; b=ikx4k/Zf3lxGOH6aGt0JJEsO36T5uG6fgOepCLKaHKbLEDp+i40ES/ZuKVRnY4cNcoyDM4 ajWRx4hj1qU8sTtHfOxFaOHvvsZQdVzIfKoMbwaH24U+v2YZs1HQvfDQBJ/JDHu7+wejFu f23yX9iA8wvkUiY0vULvaoDSV9RHTDg= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-210-l8GbICyYPK-1-G5vcsTJ2g-1; Wed, 10 Mar 2021 22:33:56 -0500 X-MC-Unique: l8GbICyYPK-1-G5vcsTJ2g-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 7FCAC83DD20; Thu, 11 Mar 2021 03:33:55 +0000 (UTC) Received: from wangxiaodeMacBook-Air.local (ovpn-13-9.pek2.redhat.com [10.72.13.9]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8059260240; Thu, 11 Mar 2021 03:33:49 +0000 (UTC) Subject: Re: [RFC PATCH v3 02/10] net: Pad short frames to minimum size before send from SLiRP/TAP To: Bin Meng References: <20210303191205.1656980-1-philmd@redhat.com> <20210303191205.1656980-3-philmd@redhat.com> <36123f35-06ab-d0da-37d2-6f8324e7f582@redhat.com> From: Jason Wang Message-ID: Date: Thu, 11 Mar 2021 11:33:48 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=jasowang@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Received-SPF: pass client-ip=63.128.21.124; envelope-from=jasowang@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -29 X-Spam_score: -3.0 X-Spam_bar: --- X-Spam_report: (-3.0 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.243, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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: Peter Maydell , Dmitry Fleytman , "Michael S. Tsirkin" , Bin Meng , Richard Henderson , QEMU Developers , =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On 2021/3/11 11:12 上午, Bin Meng wrote: > On Thu, Mar 11, 2021 at 11:01 AM Jason Wang wrote: >> >> On 2021/3/9 6:13 下午, Peter Maydell wrote: >>> On Tue, 9 Mar 2021 at 09:01, Bin Meng wrote: >>>> Hi Jason, >>>> >>>> On Tue, Mar 9, 2021 at 5:00 PM Bin Meng wrote: >>>>> Hi Jason, >>>>> >>>>> On Tue, Mar 9, 2021 at 4:57 PM Jason Wang wrote: >>>>>> On 2021/3/9 4:35 下午, Bin Meng wrote: >>>>>>> Hi Jason, >>>>>>> >>>>>>> On Tue, Mar 9, 2021 at 4:23 PM Jason Wang wrote: >>>>>>>> On 2021/3/8 6:22 下午, Peter Maydell wrote: >>>>>>>>> I think the key thing we need to do here is make a decision >>>>>>>>> and be clear about what we're doing. There are three options >>>>>>>>> I can see: >>>>>>>>> >>>>>>>>> (1) we say that the net API demands that backends pad >>>>>>>>> packets they emit to the minimum ethernet frame length >>>>>>>>> unless they specifically are intending to emit a short frame, >>>>>>>>> and we fix any backends that don't comply (or equivalently, >>>>>>>>> add support in the core code for a backend to mark itself >>>>>>>>> as "I don't pad; please do it for me"). >>>>>>>>> >>>>>>>>> (2) we say that the networking subsystem doesn't support >>>>>>>>> short packets, and just have the common code always enforce >>>>>>>>> padding short frames to the minimum length somewhere between >>>>>>>>> when it receives a packet from a backend and passes it to >>>>>>>>> a NIC model. >>>>>>>>> >>>>>>>>> (3) we say that it's the job of the NIC models to pad >>>>>>>>> short frames as they see them coming in. >>>>>>>> I'm not sure how much value we can gain from (1). So (2) looks better to me. >>>>>>>> >>>>>>>> Bin or Philippe, want to send a new version? >>>>>>>> >>>>>>> I think this series does what (2) asks for. Or am I missing anything? >>>>>> It only did the padding for user/TAP. >>>> (hit send too soon ...) >>>> >>>> Ah, so we want this: >>>> >>>> if (sender->info->type != NET_CLIENT_DRIVER_NIC) >>>> >>>> correct? >>> No, option (2) is "always pad short packets regardless of >>> sender->info->type". Even if a NIC driver sends out a short >>> packet, we want to pad it, because we might be feeding it to >>> something that assumes it does not see short packets. >>> >>> thanks >>> -- PMM >> >> So I'm not sure this is correct. There're NIC that has its own logic >> that choose whether to pad the frame during TX (e.g e1000). > Yes, that's why I mentioned in v2's cover letter that we should > probably only do the padding for SLiRP and TAP. Actually it's a partail implementation of Peter's method 1. If we go that way, you need to make sure the packet is padded for every ethernet backend not just TAP and SLIRP. > For NIC models, we can > still support sending short frames in QEMU. Then it will be padded as well. > >> 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). >> > I did read this discussion before working on this patch series. > Providing a helper for NICs to call does NOT fix the issue for SLiRP > and TAP. I'm not sure I get here. For TX, the padding is controlled by the guest driver. So we just need to emulate what real NIC did, pad only when it was required explicitly by the driver. For RX, if we receive short frames from an ethternet backend, we simply pad them to make sure it won't be dropped by the NIC model. So we're actually fine here? Thanks > >> Thanks >> >> [1] >> https://patchwork.ozlabs.org/project/qemu-devel/patch/1284842625-13920-1-git-send-email-stefanha@linux.vnet.ibm.com/ >> > Regards, > Bin >