From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-f194.google.com (mail-pl1-f194.google.com [209.85.214.194]) by dpdk.org (Postfix) with ESMTP id 52D022B8B for ; Mon, 19 Nov 2018 17:10:40 +0100 (CET) Received: by mail-pl1-f194.google.com with SMTP id s5-v6so14787554plq.11 for ; Mon, 19 Nov 2018 08:10:40 -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=IBdvvheaiLG+SaEun5oSCXK5iWclpbjIEoz+jlCNk10=; b=FKCigqnyhBrVCZ1WBM2IcOadwz/g8SypfD4Y+bA8NjtlC7CTEh65T0CgONwkhil/JT j6CM9p11eBxeYh289Net75+v8/CAOOmsPhX2u+xgTwwD59D3inccQ4pfpehOpXPP7YKk Bzon3sDdbRBj851T3B631BwctBgFEwoP/DY93dxtWW5jvdUnNGLvzXsS0RjVFHwHoM+7 NLWnWd0YQvqDoMKBBTvU3uBdKnNoytsH0Q637fHVH4pTBI4ermjGViN7qxvsOjvSqupO AAbBRl5HZSkgAL+OFOj5p1URVQfxro5IzdxkBzE5+7+S/FReHQgDr8mJa8FieWl98Lhz qh+Q== 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=IBdvvheaiLG+SaEun5oSCXK5iWclpbjIEoz+jlCNk10=; b=W6jWmNz2JeBzGj6BcJ7CLBNYIbqGPWJV/sNmdggEo5nc8Vu0c834SZtzIs3ZYHGqhx 8W0+rVREGfkKVlVQzFomDLVhJdJd+/rtd5or/SJjOhutQjecsB4zWSRhpYTiWYtURSHX f/lmLwwWACiHO0EIuD3l26dYNEfN4kP6Id4FD7Oq+DOfYfVW+JM8eb6MhiJ6FTlubdVu LizwCFQ8xLv2CE/YxQdqiivCkpMlVOhhlqrm25eda/RAvPtL+LypBXvQ/IiAkrku7wSj HXvHhj/AVU3bZzXk2fErW9R2H4/azbYSRI1yzqGTABYPrMC3Q4diEyYCqz5adunmWsxl UprA== X-Gm-Message-State: AGRZ1gJbGyUZ7gsqTQ2xmJh2AqcSR1ajP7B6ME8IfTedk+29HpHV55dn A7OYsEiF7R+fUCPyvdjIOMUGLA== X-Google-Smtp-Source: AJdET5eNC5/PwOxFNDfcxZXFo5c2GVbrroS7xrU9JvyirOShmM8+SlO7CHjBXYSPXN6xh+/WkM5Nxg== X-Received: by 2002:a17:902:b18c:: with SMTP id s12-v6mr22458232plr.16.1542643839153; Mon, 19 Nov 2018 08:10:39 -0800 (PST) Received: from xeon-e3 (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id o23-v6sm19932810pfa.112.2018.11.19.08.10.37 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 19 Nov 2018 08:10:38 -0800 (PST) Date: Mon, 19 Nov 2018 08:10:27 -0800 From: Stephen Hemminger To: Morten =?UTF-8?B?QnLDuHJ1cA==?= Cc: , "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" , "Shahaf Shuler" , "Yongseok Koh" , "K. Y. Srinivasan" , "Haiyang Zhang" , "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: <20181119081010.44e7bbd9@xeon-e3> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35B424A6@smartserver.smartshare.dk> References: <98CBD80474FA8B44BF855DF32C47DC35B424A6@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 21 Nov 2018 00:49:47 +0100 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: Mon, 19 Nov 2018 16:10:40 -0000 On Thu, 15 Nov 2018 17:56:48 +0100 Morten Br=C3=B8rup wrote: > Hi networking driver maintainers, >=20 > I suggest that the TX functions of Ethernet interface drivers accept pack= ets with less than 60 byte payload, and transmit them on the medium as vali= d Ethernet frames, i.e. by padding the packets up to the minimum Ethernet p= acket size of 64 bytes incl. Ethernet FCS, instead of discarding them. >=20 > This feature makes it easier for application developers who are using DPD= K as the lower layer in an IP stack, where lots of packets have less than 6= 0 bytes Ethernet payload, e.g. TCP SYN and TCP ACK packets. >=20 > This feature also makes it easier for application developers who are usin= g DPDK library functions that split, merge or otherwise transform packets i= nto 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 ch= eck if packets originating from the IP stack or having passed through a spl= it/merge/transform function are about to egress on an Ethernet interface, a= nd in that case, if some of the packets are less than 60 bytes (excl. Ether= net 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 byte= TCP payload (excl. 54 bytes Ethernet+IP+TCP headers) will be split into tw= o packets of respectively 1514 byte (incl. 54 bytes Ethernet+IP+TCP headers= ) and 55 bytes (incl. 54 bytes Ethernet+IP+TCP headers), and the latter mus= t be padded before it is transmitted on an Ethernet interface. >=20 >=20 > In my opinion, it should be a requirement that the Ethernet interface dri= vers ensure correct padding when egressing the packet on the medium. Altern= atively, it can be an optional feature, which could be exposed as an TX Cap= abilities flag of the driver. >=20 > What do you think? >=20 >=20 > I do not suggest any changes regarding ingress - runts (undersize Etherne= t packets) received from the medium are invalid, and should be discarded an= d counted as errors. >=20 Devices drivers should work like Linux and BSD! They must pad packets to meet any restrictions by the underlying technology. Please don't add another capability flag or other way for applications to s= ee this. DPDK already has way to many hardware capability flags. It should just happen.