net: allow fast-forwarding TSO packets

[royger]

Summary

This is important when running on a virtualized environment, where packets
might come from another VM on the same host and the segmentation might not
have happened yet because the packet has not reached a physical network
interface.

Try to handle those packets by directly forwarding them to the outbound
network interface if it also supports TSO and the input and output options
match.

Sponsored by: Citrix Systems R&D

Test Plan

FreeBSD DomU PVHVM guests cannot 'route' traffic for other Xen PV guests on same Dom0 Host.
I am linking to the PR that this is suppose to be part of the fix for.

[royger]

Add more checks to make sure the output interface supports the TSO chain.

[ae]

sys/netinet/ip_fastfwd.c

450

It isn't safe. There is no guarantee that mbuf's data will be contiguous more than sizeof(struct ip).

[royger]

sys/netinet/ip_fastfwd.c

450

What's the proper way to get the TCP payload length then?

[ae]

sys/netinet/ip_fastfwd.c

450

The easiest way is m_copydata() with proper offset.

[royger]

sys/netinet/ip_fastfwd.c

450

Thanks! Will update the patch shortly unless there are other comments.

[royger]

Use m_copydata instead of mtodo in order to get the TCP header. Using mtodo
is not correct because it's possible that the TCP header is not in the first
mbuf.

[royger]

Ping? I have this and a couple more revisions (D6656 and D6611) that I would like to get committed before the code freeze (although I consider them bug-fixes, so they could also go in during the freeze).

Thanks, Roger.

[gnn]

sys/netinet/ip_fastfwd.c

448

Minor nit but I'd prefer an extra set of braces around the first clause, before the &&

[melifaro]

sys/netinet/ip_fastfwd.c

456

Can this fancy concatenation of 8 conditions be an inline function?

[rgrimes]

sys/netinet/ip_fastfwd.c

456

Why, it isnt used in more than one place?

[melifaro]

sys/netinet/ip_fastfwd.c

456

No, I hope it will improve readability. It will also be easier to attach some comments.

[gallatin]

What device is setting up the TSO flags on incoming frames? Shouldn't it be setting up the LRO flags, and shouldn't we be checking those and converting them to TSO in the forwarding path?

[gallatin]

The TSO conventions for checksum offload is that we store the TCP pseudohdr checksum in the th->th_sum. This is done as an artifact of TCP checksum offload, however some NICs require this. This change will break those NICs unless you setup the checksum properly by

a) replacing m_pkthdr.csum_data with the offset of the TCP header's checksum field
b) replacing the full TCP checksum with the pseudohdr sum.

See, for example, sys/dev/mxge/if_mxge.c:mxge_encap_tso() as an example of how to prepare the checksum fields to be the same as what the TCP stack sends down to drivers.

[afedorov]

sys/netinet/ip_fastfwd.c

450

Is this really safe? sizeof(struct ip) == 20 bytes, but IPv4 header can be up to 60 bytes with options. I think you should use ip.ip_hl field as offset.

[gallatin]

sys/netinet/ip_fastfwd.c

450

Or check V_ip_doopts != 0, as the code above rejects packets with options if V_ip_doopts is non-zero.