On Mon, Jun 27, 2022 at 07:23:20PM +0200, Martin Pieuchot wrote:
> On 27/06/22(Mon) 19:11, Alexander Bluhm wrote:
> > On Mon, Jun 27, 2022 at 11:49:23AM +0200, Alexander Bluhm wrote:
> > > On Sat, May 21, 2022 at 10:50:28PM +0300, Vitaliy Makkoveev wrote:
> > > > This diff looks good, except the
On 27/06/22(Mon) 19:11, Alexander Bluhm wrote:
> On Mon, Jun 27, 2022 at 11:49:23AM +0200, Alexander Bluhm wrote:
> > On Sat, May 21, 2022 at 10:50:28PM +0300, Vitaliy Makkoveev wrote:
> > > This diff looks good, except the re-check after kernel lock. It???s
> > > supposed `rt??? could became
On Mon, Jun 27, 2022 at 11:49:23AM +0200, Alexander Bluhm wrote:
> On Sat, May 21, 2022 at 10:50:28PM +0300, Vitaliy Makkoveev wrote:
> > This diff looks good, except the re-check after kernel lock. It???s
> > supposed `rt??? could became inconsistent, right? But what stops to
> > make it
On Sat, May 21, 2022 at 10:50:28PM +0300, Vitaliy Makkoveev wrote:
> This diff looks good, except the re-check after kernel lock. It???s
> supposed `rt??? could became inconsistent, right? But what stops to
> make it inconsistent after first unlocked RTF_LLINFO flag check?
>
> I think this
On 18.5.2022. 17:31, Alexander Bluhm wrote:
> Hi,
>
> For parallel IP forwarding I had put kernel lock around arpresolve()
> as a quick workaround for crashes. Moving the kernel lock inside
> the function makes the hot path lock free. I see slight prerformace
> increase in my test and no lock
This diff looks good, except the re-check after kernel lock. It’s
supposed `rt’ could became inconsistent, right? But what stops to
make it inconsistent after first unlocked RTF_LLINFO flag check?
I think this re-check should gone.
> On 21 May 2022, at 19:45, Hrvoje Popovski wrote:
>
> On
On 18.5.2022. 20:52, Hrvoje Popovski wrote:
> On 18.5.2022. 17:31, Alexander Bluhm wrote:
>> Hi,
>>
>> For parallel IP forwarding I had put kernel lock around arpresolve()
>> as a quick workaround for crashes. Moving the kernel lock inside
>> the function makes the hot path lock free. I see
On 18.5.2022. 17:31, Alexander Bluhm wrote:
> Hi,
>
> For parallel IP forwarding I had put kernel lock around arpresolve()
> as a quick workaround for crashes. Moving the kernel lock inside
> the function makes the hot path lock free. I see slight prerformace
> increase in my test and no lock
> On 18 May 2022, at 18:31, Alexander Bluhm wrote:
>
> Hi,
>
> For parallel IP forwarding I had put kernel lock around arpresolve()
> as a quick workaround for crashes. Moving the kernel lock inside
> the function makes the hot path lock free. I see slight prerformace
> increase in my test
Hi,
For parallel IP forwarding I had put kernel lock around arpresolve()
as a quick workaround for crashes. Moving the kernel lock inside
the function makes the hot path lock free. I see slight prerformace
increase in my test and no lock contention in kstack flamegraph.
10 matches
Mail list logo