[ovs-discuss] Small 802.1q-prepended packets not getting through to VM

[Gregory Rose]

On 6/7/2019 5:13 PM, Steinar H. Gunderson wrote:
> On Fri, Jun 07, 2019 at 04:50:43PM -0700, Gregory Rose wrote:
>> I see your point - I think we're in agreement about well-formed 802.1q
>> packets with VLAN tags being legal at 64 bytes.  If openvswitch is not
>> stripping the tag then re-tagging (if necessary) and then padding those
>> VLAN packets then that is a bug.  I'm not sure that's the issue we're
>> encountering here.  Please correct me if I misunderstand.
> It's not the issue we're encountering here. But it is an illustration that a
> switch really needs to be able to pad; I don't believe openvswitch handles
> this situation correctly either.

Specific examples might help.  Openvswitch does pad packets - see 
pad_packet() in
../datapath/datapath.c.


>
>> My point is that incoming packets less than 64 bytes can be dropped by
>> openvswitch as undersized and any incoming packet that has a bad Ethernet
>> CRC can be dropped as well.
>>
>> Do you disagree?
> No, I agree, with one caveat: This strategy will disallow checksum offloading
> for internally-generated packets going external, which is a pretty important
> case. If you want to make use of the NIC's checksum offloading, you will need
> a modified strategy; something like:
>
>    1. For packets coming in externally (e.g., GRE, VXLAN, physical NICs),
>       drop undersized frames and frames with bad checksums, as you say.
>    2. However, for packets that originated internally (internal ports, STP,
>       LLDP) or were modified in transit (VLAN tagging/untagging), and that
>       egress, allow bad/no checksums on ingress, but pad (if needed) and
>       compute checksum on egress. This will allow you to use the NIC's
>       checksum offloading if any.
>
> I believe that in reality, #2 is already in place, _except_ that it doesn't
> pad in the situations where the NIC doesn't do it (e.g. virtio).

Yes, it's up to the NIC to do that.

>
> Do note that my bug report says that the _TCP_ checksums are wrong, not the
> Ethernet checksums; I haven't checked the latter at all. The openvswitch
> internal ports claim to support TCP checksum offloading (as can be seen with
> ethtool -k), yet do not seem to checksum packets that go to VMs.
> Interestingly, the host stack doesn't seem to care at all, so perhaps virtio
> has special rule for such packets? But when it goes to the userspace stack,
> which presumably reads raw packets and knows nothing about virtio, the
> packets end up being tunneled and sent out un-checksummed, and everything
> goes wrong.
>
> /* Steinar */

Hmm, we should fix the internal ports ethtool output to specify that it 
does not do any checksum
offloading.

I'll look into that if you would like but I can tell you that other than 
recomputing checksums for
case # 2 you mention above, I don't think there is any TCP checksum 
offloading in the SW
datapath.

- Greg