From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-f194.google.com (mail-qk1-f194.google.com [209.85.222.194]) by dpdk.org (Postfix) with ESMTP id B7BB734F3 for ; Thu, 15 Nov 2018 03:07:26 +0100 (CET) Received: by mail-qk1-f194.google.com with SMTP id d19so29527173qkg.5 for ; Wed, 14 Nov 2018 18:07:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Y5JlXYdeIyNp/spUFAw0lVrS1YAaFN3sUMkXOimCSME=; b=as66XNV1niW+tQYz31B30iKzlU7VWFAPJkoGQoOvIRoB7n2880V+YFnW6422HybMdq psY0mDNFBJSWwlN3og13BLAlBmEpn/7HbAyfg0tvsACocFGb0TzXxTxtwFl3dcOmu+Un iblrhNyCvWf075iMVsAWHha0FxzWM2JzhKxDHEadgkO6G8+ok9GYWl0QGQsQrTFRMRtf E2MPnBt4b36jofC0cM7GJcqFUtmnOuiOpmNQDzygq9QyOJ2G/G70lA9S7LPh/LdebNEw /feWhrfNW2icQ5aY7CLfYmxZsAIQ+Kojar2E/bkTLRne0zUXg4BARhyVyRmKP/e157aj ThhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Y5JlXYdeIyNp/spUFAw0lVrS1YAaFN3sUMkXOimCSME=; b=fqgwYU/blJI3G0MMlauxW631pRiXtASnoFcWvjOgzq++BlakPB+NwQ4SCLf0xrXSAc bftZrUH3lPJKg3uhweo7cIozsYHhrmXVCiH7pu6DA3kNBQn2bYuITkIk/6qHx6vK9Idh 5NNhErG94br/fA0rft57ikEoc7w3fY+UaTnuhDuI500U0ONBiGcrEPqdl+emp0jm1DGC Xy+nETY13tGcVxlAuq7oEejX80mz3VggMdWKKMjkWu1JYD4QnNJtjbWhm4nNVElwKTy5 LngLEW/HvB4U4uiiX9kq4Ia/0D8+Tn1Gto3Fnq6oGjWiLHBW0VGhxBK3tMNrcM/64KdK 20rw== X-Gm-Message-State: AGRZ1gK0BPZOrVJAusMZAowuEf/tS+yjQRPhVR1uPUb2zagEBHVZqW90 ITAURDVac6RqN/u66Rczupj79wRf5oE0rLEkkrY= X-Google-Smtp-Source: AJdET5e50BYKuMn1nj337JcO49aZZYZ7P+vihA9NI1eJtmJ5+hoVAeEXPy2GoKq165MRGvY7WD25Dt+mGMeY83KKlLE= X-Received: by 2002:aed:24c2:: with SMTP id u2mr4147150qtc.230.1542247646072; Wed, 14 Nov 2018 18:07:26 -0800 (PST) MIME-Version: 1.0 References: <9f22d7f1-080e-1663-df8d-a3893248a93d@intel.com> <4a1e4ea9-e75a-0615-dcc8-c762817f4d2e@intel.com> <98CBD80474FA8B44BF855DF32C47DC35B4248C@smartserver.smartshare.dk> In-Reply-To: From: Sam Date: Thu, 15 Nov 2018 10:07:18 +0800 Message-ID: To: keith.wiles@intel.com Cc: mb@smartsharesystems.com, "Burakov, Anatoly" , dev@dpdk.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] Where is the padding code in DPDK? 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: Thu, 15 Nov 2018 02:07:27 -0000 So, to be brief, rte_eth_rx_burst and rte_eth_tx_burst, just send mbuf, will not do anything. Is that right? Wiles, Keith =E4=BA=8E2018=E5=B9=B411=E6=9C=8815=E6= =97=A5=E5=91=A8=E5=9B=9B =E4=B8=8A=E5=8D=8812:19=E5=86=99=E9=81=93=EF=BC=9A > > > > On Nov 14, 2018, at 4:51 AM, Morten Br=C3=B8rup > wrote: > > > > Anatoly, > > > > This differs from the Linux kernel's behavior, where padding belongs in > the NIC driver layer, not in the protocol layer. If you pass a runt frame > (too short packet) to a Linux NIC driver's transmission function, the NIC > driver (or NIC hardware) will pad the frame to make it valid. E.g. look a= t > the rhine_start_tx() function in the kernel: > https://elixir.bootlin.com/linux/v4.9.137/source/drivers/net/ethernet/via= /via-rhine.c#L1800 > > The PMD in DPDK rejects the frame or extend the number of bytes to send. > Padding assumes you are zeroing out the packet to meet the NIC required > length. In PMDs unless they are concerned with security they just make su= re > the number of bytes to be sent are correct for the hardware (60 bytes min= ). > Most NICs can do this padding in hardware as the packet is sent. > > If we are talking about virtio and only talking to virtio software backen= d > then you can send any size packet, but the stacks or code receiving the > packet you need to make sure it does not throw the packet away because it > is a runt packet. Most NICs throw away Runts and are never received to > memory. In software based design like virtio you can do whatever you want > in the length, but I would suggest following the Ethernet standard anyway= . > > Now some stacks or code (like Pktgen) assume the hardware will append the > CRC (4 bytes) and this means the application needs to at least do 60 byte > frames for the PMD, unless you know the hardware will do the right thing. > The challenge is that applications in DPDK do not know the details of the > NIC at that level and should always assume the packet being sent and > received are valid Ethernet frames. This means at lease 60 bytes as all > NICs add the CRC now a days and not all of them adjust the size of the > frame. > > If you do not send the PMD a 60 byte frame then you are expecting the NIC > to handle the padding and appending the CRC or at least expecting the PMD > to adjust the size, which I know is not in all PMDs or from my dealing wi= th > writing Pktgen for DPDK. > > If you are expecting DPDK PMDs to be Linux drivers then you need to adjus= t > your thinking and only send the PMD 60 bytes at least. Unless you want to > modify all of the PMDs to force the size to 60bytes, then I have no > objection to that patch just need to get all of the PMDs maintainers to > agree with your patch. > > On RX frames of less then 64 bytes (with CRC) are runts and most NICs > today will not receive these frames unless you program the hardware to do > so. =E2=80=98In my day=E2=80=99 :-) we had collision on the wire which cr= eated a huge > amount of fragments or Runts, today is not the case with point-to-point > links we have today. > > > > > If DPDK does not pad short frames passed to the egress function of the > NIC drivers, it should be noted in the documentation - this is not the > expected behavior by protocol developers. > > > > Or even better: The NIC hardware (or driver) should ensure padding, > possibly considering it a TX Offload feature. Generating packets shorter > than 60 bytes data is common - just consider the amount of TCP ACK packet= s, > which are typically only 14 + 20 + 20 =3D 54 bytes (incl. the 14 byte > Ethernet header). > > > > > > Med venlig hilsen / kind regards > > - Morten Br=C3=B8rup > > > >> -----Original Message----- > >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Burakov, Anatoly > >> Sent: Wednesday, November 14, 2018 11:18 AM > >> To: Sam > >> Cc: dev@dpdk.org > >> Subject: Re: [dpdk-dev] Where is the padding code in DPDK? > >> > >> On 14-Nov-18 5:45 AM, Sam wrote: > >>> OK, then shortly speaking, DPDK will NOT care about padding. > >>> NIC will care about padding while send and recv with NIC. > >>> kernel will care about while send and recv with vhostuser port. > >>> > >>> Is that right? > >> > >> I cannot speak for virtio/vhost user since i am not terribly familiar > >> with them. For regular packets, generally speaking, packets shorter > >> than > >> 60 bytes are invalid. Whether DPDK does or does not care about padding > >> is irrelevant, because *you* are attempting to transmit packets that > >> are > >> not valid. You shouldn't rely on this behavior. > >> > >>> > >>> > >>> Burakov, Anatoly >>> > =E4=BA=8E2018=E5=B9=B411=E6=9C=88= 13=E6=97=A5=E5=91=A8=E4=BA=8C =E4=B8=8B=E5=8D=885:29=E5=86=99=E9=81=93=EF= =BC=9A > >>> > >>> On 13-Nov-18 7:16 AM, Sam wrote: > >>>> Hi all, > >>>> > >>>> As we know, ethernet frame must longer then 64B. > >>>> > >>>> So if I create rte_mbuf and fill it with just 60B data, will > >>>> rte_eth_tx_burst add padding data, let the frame longer then > >> 64B > >>>> > >>>> If it does, where is the code? > >>>> > >>> > >>> Others can correct me if i'm wrong here, but specifically in case > >> of > >>> 64-byte packets, these are the shortest valid packets that you > >> can > >>> send, > >>> and a 64-byte packet will actually carry only 60 bytes' worth of > >> packet > >>> data, because there's a 4-byte CRC frame at the end (see Ethernet > >> frame > >>> format). If you enabled CRC offload, then your NIC will append > >> the 4 > >>> bytes at transmit. If you haven't, then it's up to each > >> individual > >>> driver/NIC to accept/reject such a packet because it can rightly > >> be > >>> considered malformed. > >>> > >>> In addition, your NIC may add e.g. VLAN tags or other stuff, > >> again > >>> depending on hardware offloads that you have enabled in your TX > >>> configuration, which may push the packet size beyond 64 bytes > >> while > >>> having only 60 bytes of actual packet data. > >>> > >>> -- > >>> Thanks, > >>> Anatoly > >>> > >> > >> > >> -- > >> Thanks, > >> Anatoly > > > > Regards, > Keith > >