[dpdk-dev] Where is the padding code in DPDK?
Burakov, Anatoly
anatoly.burakov at intel.com
Wed Nov 14 11:17:49 CET 2018
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.burakov at intel.com
> <mailto:anatoly.burakov at 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
More information about the dev
mailing list