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]
Message-ID: <20170412131008.GC32596@lunn.ch>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ