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=-0.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,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 37EBAC433E0 for ; Tue, 9 Mar 2021 13:13:03 +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 7E7426514A for ; Tue, 9 Mar 2021 13:13:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7E7426514A 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]:35412 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lJcAX-0006at-BN for qemu-devel@archiver.kernel.org; Tue, 09 Mar 2021 08:13:01 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:55450) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lJbWw-00047a-SG for qemu-devel@nongnu.org; Tue, 09 Mar 2021 07:32:07 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:45559) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1) (envelope-from ) id 1lJbWs-0001DA-Ha for qemu-devel@nongnu.org; Tue, 09 Mar 2021 07:32:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1615293121; 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: in-reply-to:in-reply-to:references:references; bh=UrXVODly6I08ES7WBT26PuHUZBajh3oz/wacL3sMg50=; b=LwWx7nqmsdIXnBJ7tv2KRSAxn+heqKyAz22Y/AIRR2Gt/Ju7hWexWJweP0j9Vz0zT1Opys iDDcU9TZWMEXszEpjO+Bc/uSfvh5hSDAtG6DQCaGzb2UZ/dxyxvNYjWoWUcBhiqc/623q7 XgMypO2A8zy/UjAVdLV8DhtN938yc7I= 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-518-frYdxRxmOYG2UjtjR1okOA-1; Tue, 09 Mar 2021 07:30:43 -0500 X-MC-Unique: frYdxRxmOYG2UjtjR1okOA-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 25E2E801814; Tue, 9 Mar 2021 12:30:42 +0000 (UTC) Received: from [10.35.207.23] (unknown [10.35.207.23]) by smtp.corp.redhat.com (Postfix) with ESMTPS id DFFD86062F; Tue, 9 Mar 2021 12:30:39 +0000 (UTC) From: Yan Vugenfirer Message-Id: <9FFFC757-FD77-4683-8A7F-A39E2337EE2F@redhat.com> Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: [RFC PATCH v3 02/10] net: Pad short frames to minimum size before send from SLiRP/TAP Date: Tue, 9 Mar 2021 14:30:35 +0200 In-Reply-To: To: Peter Maydell References: <20210303191205.1656980-1-philmd@redhat.com> <20210303191205.1656980-3-philmd@redhat.com> <36123f35-06ab-d0da-37d2-6f8324e7f582@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=yvugenfi@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="Apple-Mail=_EAD99563-9153-4040-8623-EA6DF6E3C212" Received-SPF: pass client-ip=216.205.24.124; envelope-from=yvugenfi@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, HTML_MESSAGE=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 , Jason Wang , 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" --Apple-Mail=_EAD99563-9153-4040-8623-EA6DF6E3C212 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 9 Mar 2021, at 12:13 PM, Peter Maydell wrot= e: >=20 > On Tue, 9 Mar 2021 at 09:01, Bin Meng > wrote: >>=20 >> Hi Jason, >>=20 >> On Tue, Mar 9, 2021 at 5:00 PM Bin Meng wrote: >>>=20 >>> Hi Jason, >>>=20 >>> On Tue, Mar 9, 2021 at 4:57 PM Jason Wang wrote: >>>>=20 >>>>=20 >>>> On 2021/3/9 4:35 =E4=B8=8B=E5=8D=88, Bin Meng wrote: >>>>> Hi Jason, >>>>>=20 >>>>> On Tue, Mar 9, 2021 at 4:23 PM Jason Wang wrote= : >>>>>>=20 >>>>>> On 2021/3/8 6:22 =E4=B8=8B=E5=8D=88, 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: >>>>>>>=20 >>>>>>> (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"). >>>>>>>=20 >>>>>>> (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. >>>>>>>=20 >>>>>>> (3) we say that it's the job of the NIC models to pad >>>>>>> short frames as they see them coming in. >=20 >>>>>> I'm not sure how much value we can gain from (1). So (2) looks bette= r to me. >>>>>>=20 >>>>>> Bin or Philippe, want to send a new version? >>>>>>=20 >>>>> I think this series does what (2) asks for. Or am I missing anything? >>>>=20 >>>>=20 >>>> It only did the padding for user/TAP. >>>=20 >>=20 >> (hit send too soon ...) >>=20 >> Ah, so we want this: >>=20 >> if (sender->info->type !=3D NET_CLIENT_DRIVER_NIC) >>=20 >> correct? >=20 > 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. Some thought on this option - in such case with virtio-net, can we also get= an indication from the device that the packet will be padded? Currently we are padding short packets in Windows driver (this is MS certif= ication requirement), and it will be nice not do to this in the guest if de= vice will announce such capability. Best regards, Yan. >=20 > thanks > -- PMM --Apple-Mail=_EAD99563-9153-4040-8623-EA6DF6E3C212 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 9 Mar 2021= , at 12:13 PM, Peter Maydell <peter.maydell@linaro.org> wrote:

<= span style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size:= 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; = letter-spacing: normal; text-align: start; text-indent: 0px; text-transform= : none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: = 0px; text-decoration: none; float: none; display: inline !important;" class= =3D"">On Tue, 9 Mar 2021 at 09:01, Bin Meng <bmeng.cn@gm= ail.com> wrote:
=

Hi Jason,

O= n Tue, Mar 9, 2021 at 5:00 PM Bin Meng <bmeng.cn@gmail.com> wrote:

Hi Jason,

On Tue, Mar 9, 2021 at 4:57 PM Jason Wang <jasowang@redhat.com> wrote:


On 2021= /3/9 4:35 =E4=B8=8B=E5=8D=88, Bin Meng wrote:
Hi Jason,

On Tue, Mar 9,= 2021 at 4:23 PM Jason Wang <jasowang@redhat.com> wrote:

On 2021/3/8 6:22 =E4=B8=8B=E5=8D=88, Peter= Maydell wrote:
I think = the key thing we need to do here is make a decision
and be cl= ear about what we're doing. There are three options
I can see= :

(1) we say that the net API demands that bac= kends pad
packets they emit to the minimum ethernet frame len= gth
unless they specifically are intending to emit a short fr= ame,
and we fix any backends that don't comply (or equivalent= ly,
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 o= f 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 ve= rsion?

I think this series does w= hat (2) asks for. Or am I missing anything?


It only did the padding for user/TAP.


(hit send too so= on ...)

Ah, so we want this:
if (sender->info->type !=3D NET_CLIENT_DRIVER_NIC)

correct?

No, option (2) is "always pad short packets r= egardless of
sender->= ;info->type". Even if a NIC driver sends out a short
packet, we want to pad it, because we migh= t be feeding it to
some= thing that assumes it does not see short packets.

Some thoug= ht on this option - in such case with virtio-net, can we also get an indica= tion from the device that the packet will be padded?
Currently we= are padding short packets in Windows driver (this is MS certification requ= irement), and it will be nice not do to this in the guest if device will an= nounce such capability.

Best regards,
Yan.


thanks
-- PMM

--Apple-Mail=_EAD99563-9153-4040-8623-EA6DF6E3C212--