netdev - Re: [PATCH v2 net-next] net: stmmac: add drop transmit status feature

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 12 Apr 2017 15:10:08 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Joao Pinto <Joao.Pinto@...opsys.com>
Cc:     davem@...emloft.net, netdev@...r.kernel.org
Subject: Re: [PATCH v2 net-next] net: stmmac: add drop transmit status feature

> >> +- snps,drop-tx-status: this enables drop tx status
> > 
> > Hi Joao
> > 
> > Was the conclusion from testing that this cannot be turned on by
> > default?
> 
> This feature is great for applications that need good performance, but has a
> drawback since it has an impact in timestamp feature in Tx. There are some
> operations in PTP where the timestamp is given to the host through the TX status
> in the descriptor, so this will have an impact.
> 
> There's a way of solving this of course by making the driver checking the
> timestamp in the MAC_Tx_Timestamp_Status_XXX registers, but I can only look into
> that feature later in the future.

The problem you have is that the device tree binding is a Binary API
you have to keep backwards compatible with for the next 20 years. You
cannot drop this property when you do get around to finishing the
work. You also want to avoid adding more and more options, which
nobody knows what they do, and what best combination is to get the
best performance. You should be aiming for a driver which just works
without any configuration and with good performance.

> > What sort of performance improvement did you get? Do you have some
> > benchmark numbers?
> 
> My setup is FPGA based, so it will have lower performance values.
> Iperf results with
>   "Drop Transmit Status" set: ~650Mbps.
>   "Drop Transmit Status" unset: ~450Mbps.

What percentage of your customers use FPGAs? When i look at the users
of this driver, i see ST, Allwinner, Rockchip, Meson, etc. So silicon,
not FPGA. Does it make sense to do performance measurements on FPGA,
when you say it has lower performance?

     Andrew