Hello,
my statement here is just for the record. we should have a follow up
discussion in a different thread, which is yet to be started (when time
will come).
>
> > - Make ARP MP safe. Currently we need the kernel lock there or
> > it crashes. This creates latency for all kind of packets.
With bluhm@'s diff for parallel forwarding pipex(4) could be accessed in
parallel through (*ifp->if_input)() -> ether_input() ->
pipex_pppoe_input(). PPPOE pipex(4) sessions are mostly immutable except
MPPE crypt.
The diff below makes pipex(4) a little bit more parallelization
reliable.
The new
On Thu, Jul 22, 2021 at 12:06:09AM +0200, Hrvoje Popovski wrote:
> I'm combining this and last parallel diff and i can't see any drops in
> traffic. Even sending at high rate, traffic through iked or isakmpd is
> stable at 150Kpps, which is good ..
Thanks, good news.
> One funny thing is that wit
On 21.7.2021. 22:21, Alexander Bluhm wrote:
> Ahh, to many diffs in my tree. I have forgotten the cunk
> crp->crp_flags = ... | CRYPTO_F_NOQUEUE
>
> Try this. Still testing it myself, it looks a bit faster.
I'm combining this and last parallel diff and i can't see any drops in
traffic. Even se
On Wed, Jul 21, 2021 at 06:41:30PM +0200, Alexander Bluhm wrote:
> On Mon, Jul 19, 2021 at 07:33:55PM +0300, Vitaliy Makkoveev wrote:
> > Hi, pipex(4) is also not ready for parallel access. In the chunk below
> > it will be accessed through (*ifp->if_input)() -> ether_input() ->
> > pipex_pppoe_inp
On Wed, Jul 21, 2021 at 07:53:55PM +0200, Hrvoje Popovski wrote:
> i've applied this and ipsec crypto no queue diff and i'm getting
> splasserts below ... maybe it's something obvious, if not, i will try
> diff by diff ..
Ahh, to many diffs in my tree. I have forgotten the cunk
crp->crp_flags = .
On 21.7.2021. 18:41, Alexander Bluhm wrote:
> On Mon, Jul 19, 2021 at 07:33:55PM +0300, Vitaliy Makkoveev wrote:
>> Hi, pipex(4) is also not ready for parallel access. In the chunk below
>> it will be accessed through (*ifp->if_input)() -> ether_input() ->
>> pipex_pppoe_input(). This looks not fat
Hi,
Hrvoje had some problems with to many network packets in the unlimited
queues of the crypto task queues.
Removing the queues and just calling the crypto operations directly
improves throughput by 20%. See the sys-crypto-dispatch-klock
column.
http://bluhm.genua.de/perform/results/2021-07-21T
Hi Scott,
Scott Cheloha wrote on Wed, Jul 21, 2021 at 11:02:00AM -0500:
[ EFAULT ]
> Given deraadt@'s response I'm just going to leave the existing
> language.
Fine with me.
> I guess I will need to dig into it a bit. Finding the text of the
> really early documents, prior to SUSv2, is tricky.
On Mon, Jul 19, 2021 at 07:33:55PM +0300, Vitaliy Makkoveev wrote:
> Hi, pipex(4) is also not ready for parallel access. In the chunk below
> it will be accessed through (*ifp->if_input)() -> ether_input() ->
> pipex_pppoe_input(). This looks not fatal but makes at least session
> statistics incons
On Wed, Jul 21, 2021 at 04:00:51AM +0200, Ingo Schwarze wrote:
> Hi Scott,
>
> Scott Cheloha wrote on Tue, Jul 20, 2021 at 05:20:16PM -0500:
>
> > The nanosleep.2 page could use some cleanup. Here's a bunch of fixes,
> > rewrites, etc.
> >
> > I've included my notes on the changes below. I hav
Hi Theo,
Theo de Raadt wrote on Tue, Jul 20, 2021 at 08:14:20PM -0600:
> Ingo Schwarze wrote:
>> [EFAULT] foo points outside the process's allocated address space.
>>
>> But i don't really i like that. The word "allocated" makes me wonder
>> because it sounds too much like malloc(3) for my tas
Hi
After the last commit where consecutive `*' are folded, *pattern is
never '*' here.
Best,
Martin
Index: match.c
===
RCS file: /cvs/src/usr.bin/ssh/match.c,v
retrieving revision 1.43
diff -u -p -r1.43 match.c
--- match.c 3 No
On 11/07/21(Sun) 14:45, Visa Hankala wrote:
> On Sat, Jul 10, 2021 at 05:26:57PM +0200, Martin Pieuchot wrote:
> > One of the reasons for the drop of performances in the kqueue-based
> > poll/select is the fact that kqueue filters are called up to 3 times
> > per syscall and that they all spin on t
> Date: Wed, 21 Jul 2021 15:15:11 +1000
> From: Jonathan Matthew
>
> On Tue, Jul 20, 2021 at 02:21:39PM +0200, Mark Kettenis wrote:
> > > Date: Tue, 20 Jul 2021 21:55:56 +1000
> > > From: Jonathan Matthew
> > >
> > > On Mon, Jul 19, 2021 at 07:37:10PM -0400, Ashton Fagg wrote:
> > > > I have an
On 23/06/21(Wed) 15:53, Alexander Bluhm wrote:
> On Wed, Jun 23, 2021 at 11:40:18AM +0200, Martin Pieuchot wrote:
> > Our previous attempt [0] to replace the current select(2) implementation
> > has been reverted due to non-acceptable latency increase on sockets [1].
>
> I have measured the perfor
16 matches
Mail list logo
