From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-f196.google.com (mail-qk1-f196.google.com [209.85.222.196]) by dpdk.org (Postfix) with ESMTP id 271DD378B for ; Thu, 15 Nov 2018 03:13:51 +0100 (CET) Received: by mail-qk1-f196.google.com with SMTP id n12so29544383qkh.11 for ; Wed, 14 Nov 2018 18:13:51 -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=qY5EL7AsduOhI6wxitnkBMx+hxwY/2m3pvDtg6WQ4L4=; b=XWVkddwQFtXbwS0CUqEA7dg928G/npJk/S79ciNUPA5/UmpDrwNxv/bjpqro/dIdgj hCrkZChayoRT0tG/d249Dyq3TorDnf+FP+5X4wHYGLvcF7araX3ftwGdJmXx2L86YZBX ex4FOUL7JHFW1lq8UyGwpJrJl7K9h285HX5B5eYOkSWIpnk3XYOC7V1vSc8H6ydgx4fs zW1UgN6GEgy4lr8p5C1EhtYCIjKVurV6ux3fnYu4w6eMzN78VEH5GGMrWW09iyxSn1la NBFB3as7zK8+j5QgjlFfNRYarULhQKZwNM50r63f2Us+xs6DpbNn31NAGPC19pJKTkzF uJlw== 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=qY5EL7AsduOhI6wxitnkBMx+hxwY/2m3pvDtg6WQ4L4=; b=SYwLgoha0J+SNA1kTTqrgxXOElGGODWEa2HStM1dWhm5iPlmZY7qmUM7CcNHwKjJD8 jV2cXwGMPEewiTJ8lgYxiTS9fVv5LA6kX7pLrIGb3IfjvlI4ks4yxxA1wbJrjdxlXzaw UEuZfJXA3Qo7jbwqfRlOKztRKv/xxY4Q00xXQqxow1TJFBvDiRDoLAulfXRwbJB8nbNV J19WEHE7H1kyY5KcUz3V4g2+eODPqvEh07DyF3+o4QzqhDRXUMO16cMMZtd96OYvIHMA 8jaJsjXe5LjziisxTcI+NRzDYymYdUu3cqwxFVeEQbQBNSnlbvqBP4kDWL/6DAhLX4n5 /mGQ== X-Gm-Message-State: AGRZ1gLKyeA7Ou38bfcxPm4lAnyJ0N0TOnIG16V5PA3jEQNNxL0b1uBB auQSzLiEeL/smstxGaO4zUIY3Gi6UtVQR2QMI5w= X-Google-Smtp-Source: AJdET5cI7aMMWe1NCWpx2dppFQs5J8pNvfACrQV7V2XKLSwdDso5AG3Pljk1m7Wey6en4JwP5NJjq/wxZ+f6JT8B9Nc= X-Received: by 2002:ac8:33fc:: with SMTP id d57mr4103163qtb.82.1542248030553; Wed, 14 Nov 2018 18:13:50 -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:13:29 +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:13:51 -0000 rte_vhost_dequeue_burst and rte_vhost_enqueue_burst is the same Sam =E4=BA=8E2018=E5=B9=B411=E6=9C=8815=E6=97=A5=E5= =91=A8=E5=9B=9B =E4=B8=8A=E5=8D=8810:07=E5=86=99=E9=81=93=EF=BC=9A > 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 i= n >> the NIC driver layer, not in the protocol layer. If you pass a runt fram= e >> (too short packet) to a Linux NIC driver's transmission function, the NI= C >> driver (or NIC hardware) will pad the frame to make it valid. E.g. look = at >> the rhine_start_tx() function in the kernel: >> https://elixir.bootlin.com/linux/v4.9.137/source/drivers/net/ethernet/vi= a/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 s= ure >> the number of bytes to be sent are correct for the hardware (60 bytes mi= n). >> 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 >> backend then you can send any size packet, but the stacks or code receiv= ing >> the packet you need to make sure it does not throw the packet away becau= se >> it is a runt packet. Most NICs throw away Runts and are never received t= o >> memory. In software based design like virtio you can do whatever you wan= t >> in the length, but I would suggest following the Ethernet standard anywa= y. >> >> Now some stacks or code (like Pktgen) assume the hardware will append th= e >> CRC (4 bytes) and this means the application needs to at least do 60 byt= e >> 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 th= e >> 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 NI= C >> to handle the padding and appending the CRC or at least expecting the PM= D >> to adjust the size, which I know is not in all PMDs or from my dealing w= ith >> writing Pktgen for DPDK. >> >> If you are expecting DPDK PMDs to be Linux drivers then you need to >> adjust 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 d= o >> so. =E2=80=98In my day=E2=80=99 :-) we had collision on the wire which c= reated 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 packe= ts, >> 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 paddin= g >> >> 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= =8813=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 >> >>