On Wed, Jul 03, 2019 at 12:15:36AM +0300, Ilias Apalodimas wrote:
Hi Jesper,
Getting late here, i'll respond in detail tomorrow. One point though
[...]
This special use-case, seems confined to your driver. And Ilias told me
that XDP is not really a performance benefit for this driver as the HW
PPS-limit is hit before the XDP and netstack limit. I ask, does it
make sense to add XDP to this driver, if it complicates the code for
everybody else?
I think yes. This is a widely used driver on TI embedded devices so having XDP
to play along is a nice feature. It's also the first and only armv7 we have
supporting this. Ivan already found a couple of issues due to the 32-bit
architecture he is trying to fix, i think there's real benefit in having that,
performance aside.
I fully agree we should not impact the performance of the API to support a
special hardware though. I'll have a look on the 2 solutions tomorrow, but the
general approach on this one should be 'the simpler the better'
Cheers
/Ilias
BTW even w/o optimization it has close to 300kpps (but with increased number of
descs) on drop which is very close to netsec measurements Ilias sent. But from
what I know there is no h/w limit on cpsw at all that this CPU can serve, so
my assumption it's rather s/w limit. But that's not main here and XDP usage
has not been estimated enough yet in embedded, where hi speed not only benefit
that can be taken from XDP.
I need more clear circumstances to send v6 ...
--
Regards,
Ivan Khoronzhuk
