Re: octeon: fix cnmac corrupting VLAN packets transmitted by veb

On 14/07/2026 13:52, Visa Hankala wrote:
 > I think the initial patch could be improved a little by using
 > ether_extract_headers(). This avoids adding another custom packet
 > peeker, and adds IPv6 handling.

I agree. My patch inadvertently breaks checksumming of plain, 
unfragmented IPv6.

I have considered ether_extract_header() initially, but dismissed it 
because it
seemed like it is doing too much, compared to the ipoffp1 calculation 
code in
base.

Now it made me wonder what is actually supported by the hardware cnmac 
can bind
to.  I have hard time finding hardware specifications for Cavium processors,
but at least for CN50XX there are some caveats:

1. IP payload must be strictly TCP or UDP.
2. IPv4 must have no options (IHL=5).
3. IPv4 must not be a fragment (MF and offset must be zero).
4. IPv6 is supported, but there must be no extension headers before TCP 
or UDP
    header.

In your version of the patch we keep support for IPv6 and fulfill the
requirement #1. I hope we can commit it as a fair fix for the original 
problem
with VLAN encapsulation.

As for the rest of requirements:

#3 seems to be fulfilled because ip_fragment() calculates checksums and 
clears
the CSUM flags.

#4 seems to be a problem to follow up on. If I read ip6_output() 
correctly, it
also calculates checksums upon fragmenting but it can insert other IPv6
extension headers (hop-by-hop, dest options, etc) prior to the payload. 
It does
not happen in a basic test with nc(1), I need to investigate how to 
trigger it.
Also, I wonder if we need to worry about forwarded packets.


@kirill do you know how uniform the hardware checksumming specs are 
across the
supported Cavium chips?