Date: Sun, 26 Jan 2020 08:44:53 -1000 (HST) From: Jeff Roberson <jroberson@jroberson.net> To: John Baldwin <jhb@FreeBSD.org> Cc: Gleb Smirnoff <glebius@freebsd.org>, Ryan Stone <rysto32@gmail.com>, src-committers <src-committers@freebsd.org>, svn-src-all <svn-src-all@freebsd.org>, svn-src-head <svn-src-head@freebsd.org> Subject: Re: svn commit: r357051 - head/sys/dev/bge Message-ID: <alpine.BSF.2.21.9999.2001260840510.1198@desktop> In-Reply-To: <6a5485eb-8623-3316-0385-b0cda1624b05@FreeBSD.org> References: <202001231636.00NGawrr080128@repo.freebsd.org> <CAFMmRNyP5nKPZ62c9yRktH4t23GAgnpc2u8kHhUevUCu3doAQQ@mail.gmail.com> <20200123230546.GG1268@FreeBSD.org> <CAFMmRNwhcV-%2BSsq_a1RZJYXC8wvnUDLDxdFeHD7PgL5wuierkg@mail.gmail.com> <20200124012458.GI1268@FreeBSD.org> <CAFMmRNz3TVPfP7_fhBMa=gdN%2BM4OdCco3z1qO=mPOm57-QOsng@mail.gmail.com> <20200124024356.GK1268@FreeBSD.org> <alpine.BSF.2.21.9999.2001231657400.1198@desktop> <20200124033243.GL1268@FreeBSD.org> <6a5485eb-8623-3316-0385-b0cda1624b05@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 26 Jan 2020, John Baldwin wrote: > 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. This is actually the approach that I took for nokia. You could prefetch m->m_nextpkt at the top of the loop iteration. It was very effective there. Seeing how many drivers and unexpected entry points had to have the NET_EPOCH added I would want to review again once it's stable and see if there is a way to simplify through API changes. It seems like more than expected slipped through the cracks and I worry about long-term maintenance. Thanks, Jeff > > -- > John Baldwin >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.21.9999.2001260840510.1198>