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 <keith.wi...@intel.com> 于2018年11月15日周四 上午12:19写道： > > > > On Nov 14, 2018, at 4:51 AM, Morten Brørup <m...@smartsharesystems.com> > 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 at > 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 sure > 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 backend > 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 with > 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 do > so. ‘In my day’ :-) we had collision on the wire which created 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 packets, > which are typically only 14 + 20 + 20 = 54 bytes (incl. the 14 byte > Ethernet header). > > > > > > Med venlig hilsen / kind regards > > - Morten Brørup > > > >> -----Original Message----- > >> From: dev [mailto:dev-boun...@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 <anatoly.bura...@intel.com > >>> <mailto:anatoly.bura...@intel.com>> 于2018年11月13日周二 下午5:29写道： > >>> > >>> 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 > >
