ganne) via Lists.Fd.Io
Sent: Tuesday, October 29, 2019 11:20 AM
To: Christian Hopps ; Paul Vinciguerra
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] pg (missing) ethernet padding
> Unless there are real world scenarios where the device pg is emulating
> returns < 60b frames I think it would be
> Unless there are real world scenarios where the device pg is emulating
> returns < 60b frames I think it would be good just to fix pg to pad. If
> code breaks based on this, wouldn't that code also break when used in
> production? :)
Packet recirculating from a tunnel (eg. ethernet inner of a vx
FWIW, I recently hit a bug during a demo that I would have caught but for lack
of padding by pg in UT. In my case I had tested full spread of packet sizes
using the UT framework, but hadn't done it thoroughly enough with real
interfaces and so got bit by b->current_length > iplen with small ip p
Hi Ben.
Isn't it amazing how timing is everything. Would you believe this issue
came up in discussion yesterday? I was suggesting the use of alternate
interfaces, such as over tap/veth/af_packet over pg in tests.
If the behavior is changed, it should probably be done in a backward
compatible way
Hi all,
While working on Address Sanitizer, I realized pg pcap replay was not padding
runt frames to 60-bytes before handing them to ethernet-input. With a real NIC,
we should never get packets smaller than 60-bytes.
This means we process very short Ethernet frames in make test. It is very
comm
