Date: Fri, 24 Jan 2020 20:21:54 +0100 From: Hans Petter Selasky <hps@selasky.org> To: Gleb Smirnoff <glebius@freebsd.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r357004 - in head/sys: kern sys Message-ID: <7d7db96d-26b1-1d2b-9f8d-a3f8fbe8c33c@selasky.org> In-Reply-To: <20200124170532.GO1268@FreeBSD.org> References: <202001230124.00N1OlXi029506@repo.freebsd.org> <fb6e84b6-85a9-3252-c27a-bb9ee7ca203f@selasky.org> <23f272a4-c997-a454-19d6-10392713e71f@selasky.org> <20200124170532.GO1268@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-01-24 18:05, Gleb Smirnoff wrote: > On Fri, Jan 24, 2020 at 10:24:53AM +0100, Hans Petter Selasky wrote: > H> What you want to do here is right, but how it is implemented is wrong, > H> in my opinion. > H> > H> 1) Remove intr_epoch_batch. Most network drivers use interrupt > H> moderation, and a timeout of 1000 iterations can easily become 1 second > H> under heavly load ! > > If a driver has interrupt moderation than epoch batching counter > basically won't ever grow over 1. It kicks in only of driver doesn't > have it, or receives interrupts at a very high rate. Depending on the load an interrupt imposes, this batching counter may cause epochs to last for a long time. Have you considered using ticks for this instead? I.E. if the congestion lasts more than two ticks, then re-acquire the EPOCH? For example if the network controller spends more time processing packets then there is between interrupts, then this unconditional 1000x thing can be quite dangerous. > > H> 2) You need to make a new request function for interrupts which take a > H> pointer to an EPOCH and replace that IH_NET in hflags! > > Initially I did that way, but then pondered over this approach and have > abandoned it. Most likely we will have just few globally recognized > epochs in the kernel. And even less might be associated with interrupt > handlers. Complexity and performance impact of using a pointer are > noted by Drew in D23347. Let not the network epoch become the new Giant of EPOCH's. There might be realtime constraints for EPOCH's aswell. Secondly, I don't see how 8000 IRQs per second will cause any problem accessing a pointer in the interrupt handler structure? A well designed ethernet driver use coalescing of packets and the the IRQ rate goes down. What Drew is referring to are badly designed ethernet cards with very small DMA rings, so the speak. If the IRQ handler is executed hundreds of thousand times per second, that is a problem in itself and reading one more pointer will have little impact on the system. --HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7d7db96d-26b1-1d2b-9f8d-a3f8fbe8c33c>