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)
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Feb 1 2019
Jan 31 2019
Jan 30 2019
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
Dec 17 2018
Nov 29 2018
Nov 21 2018
Nov 20 2018
Looks good to me :)
This looks fine Michael :)
Oct 18 2018
Oct 16 2018
Aug 28 2018
Aug 27 2018
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 :)
Aug 21 2018
Aug 20 2018
Aug 18 2018
Fix the silly cut and paste bug.
This version incorporates all of Jonathans comments and suggested improvements. Thanks
Jonathan!!!
Aug 10 2018
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.
Aug 9 2018
Fixes an accounting problem shown by testing
Aug 8 2018
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.
Aug 6 2018
Aug 5 2018
Aug 3 2018
Jul 31 2018
Jul 30 2018
Jul 26 2018
Jul 24 2018
Jul 19 2018
Jul 18 2018
Jul 12 2018
Jun 21 2018
Jun 20 2018
Jun 19 2018
Jun 18 2018
Jun 14 2018
Jun 12 2018
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.
Jun 11 2018
Get the vnet set much earlier and all the right bits around earlier too.
Jun 7 2018
A couple of configs I use:
May 23 2018
May 22 2018
Looking closely at this and thinking about tcp_hpts.c, if I grok this correctly
this should all integrate ok. Assuming that someone calls inp_pcbfree() on
something that is in hpts, even if the epoch_call happens, the inpcb won't
be freed until the hpts's main loop see the INP_FREED flag and does
its in_pcbrele_wlocked() call at which time the INP will finally get destroyed.
May 9 2018
Apr 26 2018
Apr 25 2018
Yeah I had those in there in our version so I could
validate the range in amd64 with the DMAP_VM but for
some reason those don't work in head anymore.. Forgot
to purge the headers :)
Apr 20 2018
One of the nice things that having a module which is the default stack does is that
changes of any type can be made in the module. Then you can test those changes
before applying the changes to the main stack. That makes it rather nice that
one can try before we buy changes to the included stack. We have used that
fairly effectively at NF on deploying new versions of things (not the default stack but rack)
Yes I gained about 1/2Gbps of added performance in my tests.
As to VIMAGE who really uses that? No one I know of. Considering
the use of it (or lack there of) I saw of no real reason to have it
in the first-cache-line. Of course the other question is how
often does one use the back-pointer to the parent vnet.
Apr 19 2018
Apr 18 2018
Apr 12 2018
This adds the comments that Hiren had asked for and I even
add a comment block at the top of tcp_hpts.c to talk about usage
(not a design document but some hints on use). Note also Hiren
that the hpts system can be used by the default freebsd stack. Our
internal NF default stack actually has some of these hooks in it as
well so we can enable "pacing" with various options.
Thanks for looking at this. Note that rack is not in yet because it lacks this commit. This is the
first commit in the steps to get rack that we use at NF for 99% of traffic into the FreeBSD core code.
These have to go in first :)
Apr 11 2018
After jtl and I chatted I finally understand his request (just a bit thick I guess) so
now I wrap up his final comment.
This address Gleb and Jonathans comments and also now passes a build universe