User Details
- User Since
- Jun 22 2015, 5:21 PM (359 w, 6 d)
Thu, May 12
Wed, Apr 27
Nice work!!!
Apr 14 2022
Mar 18 2022
Mar 17 2022
- Added a comment to why we enable debug stuff here as per mjg's request
Mar 3 2022
I think pushing it and fixing the lagg issue after its in the tree is probably the best path forward.
Feb 14 2022
The workflow I'm referring to is easily cleaning up after applying patches with git clean, using standard arguments.
Feb 11 2022
Feb 10 2022
Feb 9 2022
Feb 8 2022
Feb 1 2022
Jan 28 2022
Jan 27 2022
Jan 26 2022
Dec 27 2021
Dec 21 2021
Dec 17 2021
Dec 15 2021
Why not just fix the driver for epoch for real so that the normal, non LRO path holds epoch and we don't need to repeatedly enter it in ether_input()? I've tried to upload an alternate patch..
Dec 3 2021
Any objection to me committing this change ?
Dec 2 2021
OK, I'm happy to keep this as a separate change. I mostly just want to get this committed so I can bring it down into our (netflix) tree and not carry a diff going forward..
- keep image->pi_entry = eh.e_entry as requested by jrt27
I've updated the patch to
- use first_exec_segment as suggested by jrtc27
- set image->pi_entry = eh.e_entry as suggested by brett_gutste.in
Nov 30 2021
I don't like that the drivers are dealing in ifps and calling things like if_getcapenable(). Establishing an interface that allowed drivers to have no knowledge of these details was one of the motivations for iflib.
Nov 23 2021
Very nice.
Nov 18 2021
Nov 16 2021
Nov 11 2021
I honestly don't care about anything other than amd64 and arm64 and wish we could remove all other architectures, so I don't want to stand in the way too much here. If you think this is the best direction to go in, then that's fine.
We already have code in ip_output() to convert to normal mbuf chains in the case that checksums are off on an egress interface. Is there something special about bridges that they fall through the cracks here?
To be honest, when I did early testing of extpgs, I found by far, hands down, the most improvement for sendfile use of extpgs on 32 bit platforms (x86), and the cases we're worried about (sw checksum) are corner cases that most people should never run into. So I'd prefer if it just defaulted to off on platforms without a direct map, but the user was allowed to force it.
Oct 22 2021
Oct 19 2021
Oct 14 2021
I'm not a fan of this added complexity, but it looks like it was done in a very careful way. I really appreciate it being done when creating the session, rather than upon enqueue.
Oct 12 2021
Oct 11 2021
Oct 6 2021
Sep 28 2021
Sep 14 2021
Sep 10 2021
Sep 5 2021
I agree that removing the indirection with a new SOCK_{SEND|RECVBUF}_LOCK() is a good idea.
Sep 4 2021
Aug 25 2021
I would do it in hn_nvs_handle_rxbuf(). Eg, take the epoch outside the for() loop, so it is held for all rx pkt reception.
Aug 24 2021
Aug 17 2021
Aug 16 2021
Aug 14 2021
Aug 11 2021
Aug 5 2021
Address new feedback from jhb:
Aug 3 2021
- Incorporated jhb's feedback
- fixed a typo in a comment
- changed alloc thread's name so that after truncation, its name appears different from the worker threads in 'ps axH'
Where is the new flag LRO_FLAG_DECRYPTED used? It seems to be write-only in this patch.
Jul 30 2021
Addressed Mark's feedback.
Jul 21 2021
Jul 15 2021
This is a driver bug. The hyperv driver appears to be using a taskqueue to inject packets into the network stack, rather than a normal interrupt handler. As such, I feel that it is the hyperv driver's responsibility to take the network epoch, and not force 99% of drivers which do the right thing to take the epoch twice.