On 1/23/20 7:32 PM, Gleb Smirnoff wrote: > On Thu, Jan 23, 2020 at 05:09:14PM -1000, Jeff Roberson wrote: > J> While we don't have a policy strictly requiring reviews it is the norm to > J> have substantial changes socialized and reviewed. I appreciate the work > J> that you are doing but it likely should've been discussed somewhere > J> more publicly. I apologized if I missed it but I don't see reference to > J> anything. > > That was https://reviews.freebsd.org/D23242
A review alone isn't sufficient for large, sweeping changes in my mind. For major changes, a thread on arch@ or net@ or the like is probably more appropriate. You can include a link to a review or git branch, etc. in that e-mail, but phabricator aren't as well suited to higher-level design-review type discussion, more for implementation-review. > J> Architecturally I am more concerned with the coarseness of net_epoch and > J> the duration of hold becoming a resource utilization problem in high > J> turn-over workloads. Like short connection tcp. Has anyone done > J> substantial testing here? epoch as it is today will hold every free > J> callback for a minimum of several clock ticks and a maximum of 2x the > J> duration of the longest epoch section time. With preemption, etc. this > J> could be 100s of ms of PCBs held. > > We also are concerned about that theoretically. Haven't yet seen effect > in practice, but our sessions are mostly longer living. First we have the > tunable to limit batching. Second, there are some ideas on how to improve > the garbage collector performance if it becomes an issue. There are other workloads than Netflix. ;) Verisign has incredibly short-lived connections with very high turnover. I think though that they have already abandoned the in-tree network stack for a userland stack built on netmap. Still, I think that there are probably other FreeBSD users that are probably somewhere in the middle that shouldn't be ignored. Packet batching would not be impossible by simply using m_nextpkt chains in mbufs passed up to ether_input and having ether_input pass them in a loop to the next higher loop (as a first step). That would reduce unlock/lock operations in drivers (for those still using locks on receive) as well as permitting ether_input to process batches under a single epoch invocation. -- John Baldwin _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
