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 82B92C433E0 for ; Tue, 9 Mar 2021 08:24:59 +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 EF64465267 for ; Tue, 9 Mar 2021 08:24:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EF64465267 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]:51578 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lJXfm-0006ZJ-0C for qemu-devel@archiver.kernel.org; Tue, 09 Mar 2021 03:24:58 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:44746) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lJXej-0005iF-3o for qemu-devel@nongnu.org; Tue, 09 Mar 2021 03:23:53 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:41778) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1) (envelope-from ) id 1lJXef-0007L3-IA for qemu-devel@nongnu.org; Tue, 09 Mar 2021 03:23:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1615278226; 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=JM7BfdgYFnNwxCqewf+vJhru+I0FwOAaKVxDZgQpIiE=; b=V/tdS7UNxjzfuCThj+oGjuEf+UX5ryFdJ9TP8NQH35nNcqGq3+QGDPD9S0bJLRSd4QdDT3 0NZNB/wp9iwat4vcraZX672e/HM2Gns9eD9ubXbjPFYGdvAf0Qww3+qxIj0yfKRjDzsgVC SJ1PeXHQono4XjXyafSHvHNTSVAqeRQ= 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-345-uQ9Lp-eOOO6aWukluQP6yQ-1; Tue, 09 Mar 2021 03:23:44 -0500 X-MC-Unique: uQ9Lp-eOOO6aWukluQP6yQ-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 6D840101F00B; Tue, 9 Mar 2021 08:23:43 +0000 (UTC) Received: from wangxiaodeMacBook-Air.local (ovpn-12-195.pek2.redhat.com [10.72.12.195]) by smtp.corp.redhat.com (Postfix) with ESMTP id 32C8B5D9D3; Tue, 9 Mar 2021 08:23:40 +0000 (UTC) Subject: Re: [RFC PATCH v3 02/10] net: Pad short frames to minimum size before send from SLiRP/TAP To: Peter Maydell 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: Tue, 9 Mar 2021 16:23:39 +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.14 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=216.205.24.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.251, 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_H3=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: Dmitry Fleytman , Bin Meng , Richard Henderson , QEMU Developers , Bin Meng , =?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/8 6:22 下午, Peter Maydell wrote: > On Mon, 8 Mar 2021 at 03:48, Jason Wang wrote: >> Do we need to care about other type of networking backends? E.g socket. >> >> Or at least we should keep the padding logic if we can't audit all of >> the backends. > 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 think (3) is pretty clearly the worst of these, since it > requires every NIC model to handle it; it has no advantages > over (2) that I can see. I don't have a strong take on whether > we'd rather have (1) or (2): it's a tradeoff between whether > we support modelling of short frames vs simplicity of code. > I'd just like us to be clear about what point or points in > the code have the responsibility for padding short frames. 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? Thanks > > On > + if (sender->info->type == NET_CLIENT_DRIVER_USER || > + sender->info->type == NET_CLIENT_DRIVER_TAP) { > > vs >> if (sender->info->type != NET_CLIENT_DRIVER_NIC) > another option would be to add a 'bool pad_short_tx_frames' to > the NetClientInfo struct, and have those things which don't > pad set it to true. > > thanks > -- PMM >