get the update in and fix the pesky extra line.

Update to hopefully get a better view and not have the stray line in the diff

Interesting my svn copy does not have that extra chunk.. let me re-update the diff and use -x -up

This updates the diff to Fix Hann's point on vlans, both the
vlan and lagg are now balanced.

Ahh good catch I did not know vlan had an allocator.. I will add it to the patch-set

I don't follow your suggestion. Why would I add a if_snd_tag_free() in if_attach_internal() .
The driver below has to do that just like it has to add the if_snd_tag_alloc(). The
internal function has no way of knowing what is the right thing to do in
freeing a tag that the driver allocates. Having it be NULL as the default in
the internal just the same as if_snd_tag_alloc() is the right thing, only
if a driver sets these should they get used (when RATELIMIT is configured of course)

In D19032#406766, @hselasky wrote:

Hi,

This patch does not look correct. You will need to pass the flowid in order to correctly handle this inside lagg?

Why are you not using the tag->ifp->if_sndtag_free(tag) in the first place?

--HPS

Hann's

Good catch Michael!!!

Looks good to me :)

This looks fine Michael :)

Because in order to conserve space the fid in the in_pcb (IIRR) is a uint16_t.. I was thinking
64k cpu's is probably enough for now :)

Fix the silly cut and paste bug.

This version incorporates all of Jonathans comments and suggested improvements. Thanks
Jonathan!!!

This version updates from the last to include all of Lawrence Stewarts comments
as well as those from Peter Lei. A significant change is altering the calculate
overhead function to also glean the mlast so that a second walk of the mbuf
chain is no longer needed.

Fixes an accounting problem shown by testing

Testing with INVAR found a problem with my late morning last optimization. If the
seq is behind us but overlaps we can't do the optimization.

Update my typo :)

Turns out after looking at Larry's last core and contemplating it a bit if it
would have succeeded (which it did not) we would have crashed anyway.
This is because the SYN got included in the send_map and we would have
tried to trim 14 instead of the 13 that bytes in the socketbuffer. Fixing that
means the send_map cannot start at snd_una for the TFO case. This means
a bit more special code needs also to be added to the SYN_SENT case then
so you end up incrementing snd_una when you move to established and that
way when you call the ack processing code all will be well :)

So this is weird we look like we sent a TFO and then hit a retransmit.. but somehow
the TFO flags was removed so we did not set len == 0 on having a SYN retransmitted.

Get the vnet set much earlier and all the right bits around earlier too.