netdev - Re: Re: [PATCH net-next] net/packet: fix TPACKET

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <CAF=yD-KzBEPsLOAG3G1bVu1zGHqJ5fHjwLC2vEtkJpSDu0Oqrg@mail.gmail.com>
Date:   Wed, 25 Mar 2020 21:16:16 -0400
From:   Willem de Bruijn <willemdebruijn.kernel@...il.com>
To:     yang_y_yi <yang_y_yi@....com>
Cc:     Network Development <netdev@...r.kernel.org>, u9012063@...il.com,
        yangyi01@...pur.com
Subject: Re: Re: [PATCH net-next] net/packet: fix TPACKET_V3 performance issue
 in case of TSO

On Wed, Mar 25, 2020 at 10:46 AM yang_y_yi <yang_y_yi@....com> wrote:
>
> Yes, hrtimer is better, but it will change current API semantics.
>
> req.tp_retire_blk_tov means millisecond, if we change it as microsecond, it will break ABI.

That can be resolved by adding a new feature flag that reinterprets
the field in the request.

#define TP_FT_REQ_USEC      0x2

Please remember to use plain text and don't top paste.



> At 2020-03-25 22:37:59, "Willem de Bruijn" <willemdebruijn.kernel@...il.com> wrote:
> >On Wed, Mar 25, 2020 at 10:10 AM <yang_y_yi@....com> wrote:
> >>
> >> From: Yi Yang <yangyi01@...pur.com>
> >>
> >> TPACKET_V3 performance is very very bad in case of TSO, it is even
> >> worse than non-TSO case. For Linux kernels which set CONFIG_HZ to
> >> 1000, req.tp_retire_blk_tov = 1 can help improve it a bit, but some
> >> Linux distributions set CONFIG_HZ to 250, so req.tp_retire_blk_tov = 1
> >> actually means req.tp_retire_blk_tov = 4, it won't have any help.
> >>
> >> This fix patch can fix the aforementioned performance issue, it can
> >> boost the performance from 3.05Gbps to 16.9Gbps, a very huge
> >> improvement. It will retire current block as early as possible in
> >> case of TSO in order that userspace application can consume it
> >> in time.
> >>
> >> Signed-off-by: Yi Yang <yangyi01@...pur.com>
> >
> >I'm not convinced that special casing TSO packets is the right solution here.
> >
> >We should consider converting TPACKET_V3 to hrtimer and allow usec
> >resolution block timer.
> >
> >Would that solve your issue?