TCP_INFO for offloaded connections.

[np]

Summary

Add a toedev hook to allow the driver handling an offloaded connection to
provide accurate TCP_INFO.

[kbowling]

This should use some kind of serdes to the toe understanding of tcpi is not dependent on the freebsd understanding of tcpi (which is in flux atm)

[np]

In D14816#311651, @kevin.bowling_kev009.com wrote:

This should use some kind of serdes to the toe understanding of tcpi is not dependent on the freebsd understanding of tcpi (which is in flux atm)

Hi Kevin,

I'm not sure I fully understood your comment. See D14817 for the driver implementation -- that's the part that fetches up-to-date state from the hardware and fills up some of the tcpi fields.

This feature is being implemented to support userspace tools to monitor the state of TCP connections of interest (including those being handled by cxgbe's TOE).

[jhb]

I don't think we need an explicit shim between TOE drivers and the kernel to try to insulate from changes to 'tcp_info'. 'tcp_info' is already part of the userland ABI, so changes to its layout are already going to require compat shims, etc. (probably a new socket option enum for the new layout, etc.) such that we should be hesitant to change it very often. For KBI breakage you would only have to worry about altering the layout of existing fields in a stable branch (whereas ABI breakage spans multiple stable branches). We already have padding fields to permit adding new fields in our current stable branches. Do we think there are future changes to 'tcp_info' that can't be accommodated by the existing padding fields?

[jason_eggnet.com]

Any radical departure from the current behavior of basically creating and copying struct tcp_info to user space would require a different getsockopt() optname at a bare minimum, and we'd still have to support the current TCP_INFO getsockopt() anyway.

I'm not seeing a problem with @jhb's approach.

[np]

Kevin mentioned offline that he has no objections to this change. Anyone else want to review?