On Fri, Apr 08, 2022 at 12:56:12PM +0200, Alexander Bluhm wrote:
> Hi,
>
> I now the right time to commit the parallel forwarding diff?
>
> Known limitiations are:
> - Hrvoje has seen a crash with both pfsync and ipsec on his production
> machine. But he cannot reproduce it in his lab.
> -
On Mon, Apr 18, 2022 at 12:27:23PM +0200, Hrvoje Popovski wrote:
> On 8.4.2022. 12:56, Alexander Bluhm wrote:
> > I now the right time to commit the parallel forwarding diff?
> >
> > Known limitiations are:
> > - Hrvoje has seen a crash with both pfsync and ipsec on his production
> > machine.
On 8.4.2022. 12:56, Alexander Bluhm wrote:
> Hi,
>
> I now the right time to commit the parallel forwarding diff?
>
> Known limitiations are:
> - Hrvoje has seen a crash with both pfsync and ipsec on his production
> machine. But he cannot reproduce it in his lab.
This is resolved. At least
Hi,
I now the right time to commit the parallel forwarding diff?
Known limitiations are:
- Hrvoje has seen a crash with both pfsync and ipsec on his production
machine. But he cannot reproduce it in his lab.
- TCP processing gets slower as we have an additional queue between
IP and protocol
> On 30 Dec 2021, at 11:28, YASUOKA Masahiko wrote:
>
> Hi,
>
> On Sat, 25 Dec 2021 21:50:47 +0300
> Vitaliy Makkoveev wrote:
>> On Fri, Dec 24, 2021 at 12:50:23PM +0100, Alexander Bluhm wrote:
>>> On Fri, Dec 24, 2021 at 04:16:28PM +0900, YASUOKA Masahiko wrote:
> - npppd l2pt
Hi,
On Sat, 25 Dec 2021 21:50:47 +0300
Vitaliy Makkoveev wrote:
> On Fri, Dec 24, 2021 at 12:50:23PM +0100, Alexander Bluhm wrote:
>> On Fri, Dec 24, 2021 at 04:16:28PM +0900, YASUOKA Masahiko wrote:
>> > > - npppd l2pt ipsecflowinfo is not MP safe
>> >
>> > Does this mean the things we are
On 25.12.2021. 18:52, Alexander Bluhm wrote:
> On Sat, Dec 25, 2021 at 09:24:07AM +0100, Hrvoje Popovski wrote:
>> On 24.12.2021. 0:55, Alexander Bluhm wrote:
>>> I think we can remove the ipsec_in_use workaround now. The IPsec
>>> path is protected with the kernel lock.
>>>
>>> There are some
On Fri, Dec 24, 2021 at 12:50:23PM +0100, Alexander Bluhm wrote:
> On Fri, Dec 24, 2021 at 04:16:28PM +0900, YASUOKA Masahiko wrote:
> > > - npppd l2pt ipsecflowinfo is not MP safe
> >
> > Does this mean the things we are discussing on the "Fix
> > ipsp_spd_lookup() for transport mode" thread? I
On Sat, Dec 25, 2021 at 09:24:07AM +0100, Hrvoje Popovski wrote:
> On 24.12.2021. 0:55, Alexander Bluhm wrote:
> > I think we can remove the ipsec_in_use workaround now. The IPsec
> > path is protected with the kernel lock.
> >
> > There are some issues left:
> > - npppd l2pt ipsecflowinfo is
On 24.12.2021. 0:55, Alexander Bluhm wrote:
> I think we can remove the ipsec_in_use workaround now. The IPsec
> path is protected with the kernel lock.
>
> There are some issues left:
> - npppd l2pt ipsecflowinfo is not MP safe
> - the acquire SA feature is not MP safe
> - Hrvoje has seen a
`rtt_link’ list also has missing protection when rtfree() called
outside netlock.
> On 25 Dec 2021, at 01:34, Alexander Bluhm wrote:
>
> On Fri, Dec 24, 2021 at 02:04:17PM +0100, Alexander Bluhm wrote:
>> On Fri, Dec 24, 2021 at 12:55:04AM +0100, Alexander Bluhm wrote:
>>> If you use only
On Fri, Dec 24, 2021 at 02:04:17PM +0100, Alexander Bluhm wrote:
> On Fri, Dec 24, 2021 at 12:55:04AM +0100, Alexander Bluhm wrote:
> > If you use only regular IPsec or forwarding, I hope it is stable.
>
> false hope
>
> rt_timer_add(fd81b97f5390,814218b0,802040c0,0) at
>
On Fri, Dec 24, 2021 at 12:55:04AM +0100, Alexander Bluhm wrote:
> If you use only regular IPsec or forwarding, I hope it is stable.
false hope
rt_timer_add(fd81b97f5390,814218b0,802040c0,0) at rt_timer_
add+0xc7
icmp_mtudisc_clone(2438040a,0,1) at icmp_mtudisc_clone+0x174
On Fri, Dec 24, 2021 at 04:16:28PM +0900, YASUOKA Masahiko wrote:
> > - npppd l2pt ipsecflowinfo is not MP safe
>
> Does this mean the things we are discussing on the "Fix
> ipsp_spd_lookup() for transport mode" thread? I wonder if there is
> another issue.
In this mail thread I was concerned
Hello,
On Fri, 24 Dec 2021 00:55:04 +0100
Alexander Bluhm wrote:
> On Fri, Dec 03, 2021 at 08:35:45PM +0100, Alexander Bluhm wrote:
>> Note that IPsec still has the workaround to disable multiple queues.
>
> I think we can remove the ipsec_in_use workaround now. The IPsec
> path is protected
On Fri, Dec 03, 2021 at 08:35:45PM +0100, Alexander Bluhm wrote:
> Note that IPsec still has the workaround to disable multiple queues.
I think we can remove the ipsec_in_use workaround now. The IPsec
path is protected with the kernel lock.
There are some issues left:
- npppd l2pt ipsecflowinfo
On Sat, Dec 04, 2021 at 10:41:02AM +0100, Hrvoje Popovski wrote:
> r620-2# uvm_fault(0x8229d4e0, 0x137, 0, 2) -> e
> kernel: page fault trap, code=0
> Stopped at ipsp_spd_lookup+0xa2f: movq%rax,0(%rcx)
> TIDPIDUID PRFLAGS PFLAGS CPU COMMAND
> 419237 67407
On 4.12.2021. 10:41, Hrvoje Popovski wrote:
> On 3.12.2021. 20:35, Alexander Bluhm wrote:
>> Hi,
>>
>> After implementing MP safe refcounting for IPsec TDB, I wonder how
>> stable my diff for forwarding on multiple CPU is.
>>
>> Note that IPsec still has the workaround to disable multiple queues.
On 4.12.2021. 10:41, Hrvoje Popovski wrote:
> Hi,
>
> with only plain forwarding it seems that everything works just fine, but
> with ipsec i'm getting this panic. i will leave ddb console active if
> something else will be needed
regarding performance ... without diff i'm getting 1.1Mpps and
On 3.12.2021. 20:35, Alexander Bluhm wrote:
> Hi,
>
> After implementing MP safe refcounting for IPsec TDB, I wonder how
> stable my diff for forwarding on multiple CPU is.
>
> Note that IPsec still has the workaround to disable multiple queues.
> We do not have a mutex that protects the TDB
On Fri, Dec 03, 2021 at 08:35:45PM +0100, Alexander Bluhm wrote:
> Hi,
>
> After implementing MP safe refcounting for IPsec TDB, I wonder how
> stable my diff for forwarding on multiple CPU is.
>
> Note that IPsec still has the workaround to disable multiple queues.
> We do not have a mutex that
Hi,
After implementing MP safe refcounting for IPsec TDB, I wonder how
stable my diff for forwarding on multiple CPU is.
Note that IPsec still has the workaround to disable multiple queues.
We do not have a mutex that protects the TDB fields yet. We have
only fixed the memory management.
My
22 matches
Mail list logo
