Re: [dpdk-dev] Where is the padding code in DPDK?

["Burakov, Anatoly" <anatoly.burakov@intel.com>]

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@intel.com 
> <mailto:anatoly.burakov@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