From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-f195.google.com (mail-pl1-f195.google.com [209.85.214.195]) by dpdk.org (Postfix) with ESMTP id A87D258C6 for ; Wed, 21 Nov 2018 01:55:27 +0100 (CET) Received: by mail-pl1-f195.google.com with SMTP id f12-v6so2846538plo.1 for ; Tue, 20 Nov 2018 16:55:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=V4C4w4QIQlkzquvpvnIw6sWcvaBq2y0H1MCzIvJ5570=; b=BQctSm8EkZg9mttyPl+ZwRYiSj8gRrpujbPrOlLFS4Nih4CUffYLzelGULAJAypBVe AsK9dkqEatO3rd/GbV5cPIEVBJZYThC4J+PmeRYzP+2Eyefn89CRtGmj4OEjcQqPNEV7 QSybN4Nf+ShQueiWSCFmY2eA8QfFEK6evj2Z8NmP9feXFhV5nkTYXs6rxozL7imQKiya pGzmbuH7+HkC4QkkyENTposIBqClKiv5ghHOzZsBlgF5Nj5GdmgoMl7yivaAZlIpi3PS mrMwPZOEeYNHqzMKAndJrQIn5zxkmUsdO6BZ1JAYJ0N1dVCcTqZO5+vWHzhIA09uQmE8 LG9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=V4C4w4QIQlkzquvpvnIw6sWcvaBq2y0H1MCzIvJ5570=; b=V8qd6HP5fqjPGK7O7fO/iVCiK1YDN0eN842x+/tveokzohI/a0mcXf9qHsnSjTbjTF PiXdgyPn3etnSlCtgMeszXIV+MLPVZpFSjeIBuIh93uo9Y/zTtj7Tp57mZt7albvjaFo V1QQ++2aGLrjJ3J+v2tI8EiLw0ALy+8iLEBRu/wq5b89BchRAHxM7pvyGNGjb2GeV+s0 LLJXQWUmVe4xxQZPBPmfmXeKZ3X6L4dx/Bl+z/t8SQUV7DYE05dP93ZkrcHKAO44u8gc QafH99xNzqPd1YVcZ0+hp3gBLbJai7Lc91ndYZ1THaFyT0q2U7Ic/Vf1ElJl5lObIXyk Ncew== X-Gm-Message-State: AA+aEWaTkRb2wEx71jkcEFwripgbjkcT9jKhKwBqNJjyy52IIOu/rLAL tR1JSt5u8T4jr1yO5bgnCjkSTA== X-Google-Smtp-Source: AFSGD/WoppNwEU7ZI4YcS2GgSPmfmSqa0ifltmQmqTHzu6xcEDGPjFJgnRyLTaXpFQHH/ZLoGQs9TA== X-Received: by 2002:a63:f615:: with SMTP id m21mr4101716pgh.428.1542761726447; Tue, 20 Nov 2018 16:55:26 -0800 (PST) Received: from xeon-e3 (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id u19-v6sm51820606pfh.153.2018.11.20.16.55.24 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 20 Nov 2018 16:55:26 -0800 (PST) Date: Tue, 20 Nov 2018 16:55:17 -0800 From: Stephen Hemminger To: Shahaf Shuler Cc: Morten =?UTF-8?B?QnLDuHJ1cA==?= , "dev@dpdk.org" , Ferruh Yigit , Declan Doherty , Chas Williams , "John W. Linville" , Marcin Wojtas , Michal Krawczyk , Guy Tzalik , Evgeny Schemeilin , Ravi Kumar , Igor Russkikh , Pavel Belous , Shepard Siegel , Ed Czeck , John Miller , Ajit Khaparde , Somnath Kotur , Jerin Jacob , Maciej Czekaj , Shijith Thotton , Srisivasubramanian Srinivasan , Rahul Lakkireddy , John Daley , Hyong Youb Kim , Wenzhuo Lu , Konstantin Ananyev , Beilei Xing , Qi Zhang , Xiao Wang , Jingjing Wu , Tomasz Duszynski , Dmitri Epshtein , Natalie Samsonov , Zyta Szpak , Matan Azrad , Yongseok Koh , kys , haiyangz , Jan Remes , Alejandro Lucero , Hemant Agrawal , Shreyansh Jain , Gagandeep Singh , Pankaj Chauhan , Harish Patil , Rasesh Mody , Shahed Shaikh , Andrew Rybchenko , Yong Wang , Maxime Coquelin , Tiwei Bie , Zhihong Wang , Allain Legacy , Matt Peters , Keith Wiles , Bruce Richardson , Tetsuya Mukawa , Gaetan Rivet , Jasvinder Singh , Cristian Dumitrescu Message-ID: <20181120165517.28b21004@xeon-e3> In-Reply-To: References: <98CBD80474FA8B44BF855DF32C47DC35B424A6@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [RFC] Ethernet drivers to add padding on egress X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2018 00:55:28 -0000 On Mon, 19 Nov 2018 08:02:02 +0000 Shahaf Shuler wrote: > Thursday, November 15, 2018 6:57 PM, Morten Br=C3=B8rup: > > Subject: [RFC] Ethernet drivers to add padding on egress > >=20 > > Hi networking driver maintainers, > >=20 > > I suggest that the TX functions of Ethernet interface drivers accept pa= ckets > > with less than 60 byte payload, and transmit them on the medium as valid > > Ethernet frames, i.e. by padding the packets up to the minimum Ethernet > > packet size of 64 bytes incl. Ethernet FCS, instead of discarding them. > >=20 > > This feature makes it easier for application developers who are using D= PDK as > > the lower layer in an IP stack, where lots of packets have less than 60= bytes > > Ethernet payload, e.g. TCP SYN and TCP ACK packets. > >=20 > > This feature also makes it easier for application developers who are us= ing > > DPDK library functions that split, merge or otherwise transform packets= into > > packets of other sizes, e.g. Generic Segmentation Offload, IP Fragmenta= tion > > and various tunnel encapsulation/decapsulation functions. > >=20 > > Currently (without this feature), it is required by the application to = check if > > packets originating from the IP stack or having passed through a > > split/merge/transform function are about to egress on an Ethernet inter= face, > > and in that case, if some of the packets are less than 60 bytes (excl. = Ethernet > > FCS), add padding before passing them on to the driver's TX function. > >=20 > > E.g. when using Generic Segmentation Offload, a packet carrying 1461 by= te > > TCP payload (excl. 54 bytes Ethernet+IP+TCP headers) will be split into= two > > packets of respectively 1514 byte (incl. 54 bytes Ethernet+IP+TCP heade= rs) > > and 55 bytes (incl. 54 bytes Ethernet+IP+TCP headers), and the latter m= ust > > be padded before it is transmitted on an Ethernet interface. > >=20 > >=20 > > In my opinion, it should be a requirement that the Ethernet interface d= rivers > > ensure correct padding when egressing the packet on the medium. > > Alternatively, it can be an optional feature, which could be exposed as= an TX > > Capabilities flag of the driver. > >=20 > > What do you think? =20 >=20 > I think at the first stage it should be a Tx offload capability - the abi= lity to pad (maybe in HW) the packets and avoid the cost of padding in SW. > PMD vendors who wants to make an easier life for their customers can impl= ement it in SW, however the gain here is only with simplicity of code for a= pplication. Performance wise it wouldn't matter.=20 >=20 > When the majority/all PMDs will have this feature we can discuss on makin= g it a standard for each PMD (like the CRC strip we have today). Yet another tx offload flag may look good as a vendor but doesn't add anyth= ing useful and hurts useablity. Every driver should take any size Ethernet packet and pad in hardware (or s= oftware) based on what it knows the NIC hardware can do. For virtual devices where there is no minimum length is required, then noth= ing needs to be done. Packets < Ether header are obvious errors and should increment tx_output er= rors.