Date: Wed, 22 Jan 2020 16:29:03 -0800 From: Gleb Smirnoff <glebius@freebsd.org> To: Michael Tuexen <Michael.Tuexen@macmic.franken.de> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r356989 - head/sys/netinet Message-ID: <20200123002903.GA1268@FreeBSD.org> In-Reply-To: <E9B1BDEF-59BD-43E6-A056-C9E9C2D2543C@macmic.franken.de> References: <202001221719.00MHJrvq033961@repo.freebsd.org> <E9B1BDEF-59BD-43E6-A056-C9E9C2D2543C@macmic.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Michael, On Wed, Jan 22, 2020 at 10:20:55PM +0100, Michael Tuexen wrote: M> > Log: M> > Plug possible calls into ip6?_output() without network epoch from SCTP M> > bluntly adding epoch entrance into the macro that SCTP uses to call M> > ip6?_output(). This definitely will introduce several epoch recursions. M> Can you specify under which condition NET_EPOCH_ENTER() should be called? M> Then I can try to figure out where these calls need to be made in the M> SCTP code. Thanks a lot for offering help! Basically the end goal is that any non-sleepable context associated with networking should be running in epoch. That means interrupts, callouts and taskqueues. Syscalls should enter epoch at some stage, depends on a syscall. Right now we are processing all incoming packets that came through ether_input() in the network epoch, so anytime we call sctp_output() as a _response_ to a packet that came via sctp_input() we already are in epoch. With r356989 it is going to be unnecessary recursion. When we do retransmits from a callout, then we aren't (yet) in epoch and r356989 addresses that. Same for syscalls that start SCTP connection or send data down SCTP socket. -- Gleb Smirnoff
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200123002903.GA1268>