Again, I would suggest not to spent padding in the main branch. This is a more generic question than scope of this change. There are two strategies:

• Don't spend padding in the main branch, always make the structure larger. When merging to stable/N, spend padding there, to make structure compatible. On branching new stable/N+1 no action required.
• Spend padding in the main branch. Merge to stable/N without adjustments. Just before branching new stable/N+1 a bunch of padding shall be added.

Pros of first strategy: we can't screw up at branching point and end up with to little padding in a stable branch, which we can't extend later. Cons of first strategy: increased number of ABI breakages in the main branch.
Pros/cons of seconds strategy - the opposite.

I'm strongly advocating towards the first one. But I will easily yield if majority disagrees. I think we should have a defined policy here, to avoid this discussion every time.

Just two notes:

• Using padding fields only provides backwards compatibility if you add fields *just* before the the padding and then reduce the padding. This is not the case with your change. I don't think it can be MFCed.
• Not sure if it makes sense to add all kind of fields without having a plan to populate them. Maybe just add the fields you actually want to fill in?

I'm a little confused about the tcp_info struct - there are already lots of unused fields; supposedly to have ABI compatibility with linux... so my understanding was, if taking in new fields for tcp_info from Linux, make sure that the remainder of the struct aligns..

(Also, some of these fields sound like they could be populated by RACK/BBR etc)