| Message ID | 20191230143028.27313-1-alobakin@dlink.ru (mailing list archive) |
|---|---|
| Headers | show |
| Series | net: dsa: add GRO support | expand |
> I mark this as RFC, and there are the key questions for maintainers, > developers, users etc.: > - Do we need GRO support for DSA at all? > - Does this series bring any performance improvements on the > affected systems? Hi Alexander I think these are the two most important questions. Did you do any performance testing for the hardware you have? I personally don't have any of the switches you have made modifications to, so i cannot test these patches. I might be able to add GRO to DSA and EDSA, where i can do some performance testing. Andrew
Hi Alexander, On Mon, 30 Dec 2019 at 16:31, Alexander Lobakin <alobakin@dlink.ru> wrote: > > I mark this as RFC, and there are the key questions for maintainers, > developers, users etc.: > - Do we need GRO support for DSA at all? > - Which tagger protocols really need it and which don't? > - Does this series bring any performance improvements on the > affected systems? If these are these questions for maintainers, developers, users etc, then what has determined you to make these changes? Thanks, -Vladimir
Andrew Lunn wrote 30.12.2019 20:12: >> I mark this as RFC, and there are the key questions for maintainers, >> developers, users etc.: >> - Do we need GRO support for DSA at all? > >> - Does this series bring any performance improvements on the >> affected systems? > > Hi Alexander Hi, > I think these are the two most important questions. Did you do any > performance testing for the hardware you have? Exactly, this are the top questions. I performed lots of tests on hardware with which I'm working on and had a pretty good boosts (I didn't mainlined my drivers yet unfortunately). But this does not mean that GRO would be that nice for all kind of devices *at all*. That's why I would like to see more test results on different systems. > I personally don't have any of the switches you have made > modifications to, so i cannot test these patches. I might be able to > add GRO to DSA and EDSA, where i can do some performance testing. > > Andrew Regards, ᚷ ᛖ ᚢ ᚦ ᚠ ᚱ
Vladimir Oltean wrote 31.12.2019 18:32: > Hi Alexander, Hi, > On Mon, 30 Dec 2019 at 16:31, Alexander Lobakin <alobakin@dlink.ru> > wrote: >> >> I mark this as RFC, and there are the key questions for maintainers, >> developers, users etc.: >> - Do we need GRO support for DSA at all? >> - Which tagger protocols really need it and which don't? >> - Does this series bring any performance improvements on the >> affected systems? > > If these are these questions for maintainers, developers, users etc, > then what has determined you to make these changes? The main reason was obviously pretty good results on a particular hardware on which I developed this (and other) series and a general opinion that GRO improves overall performance on most systems. DSA is a special case though. > Thanks, > -Vladimir Regards, ᚷ ᛖ ᚢ ᚦ ᚠ ᚱ
As of now, napi_gro_receive() in cases where the corresponding device is installed as CPU port of DSA-driven switch is in fact an overheaded version of netif_receive_skb{,_list}() with no advantages over: - dev_gro_receive() can't find packet_offload for ETH_P_XDSA type; - so it immediately returns GRO_NORMAL; - napi_skb_finish() passes skb to gro_normal_one() -> netstack. This series adds a basic infrastructure to allow DSA taggers to implement GRO callbacks and adds GRO support for 5 tagger drivers: * tag_ar9331 * tag_gswip * tag_lan9303 * tag_mtk * tag_qca I didn't make it for the rest because they are in fact way more complicated (e.g. combined DSA + 802.1q tag etc.) and require more familiarity with them and tests on the real hardware, which is inaccesible for me at the moment. This series also includes a bunch of random fixes in several tagger drivers and some cleanup. I left them all in one place as they depend on each other, but there's no problem for me to split this into different series. I mark this as RFC, and there are the key questions for maintainers, developers, users etc.: - Do we need GRO support for DSA at all? - Which tagger protocols really need it and which don't? - Are the actual changes correct in every single tagger code? - Does this series bring any performance improvements on the affected systems? - Would anybody mind if we'd add DSA support to napi_gro_frags()? - Any code/other comments/notes. I also would like to see more taggers with GRO callbacks, such as DSA and EDSA, and the results of their addition. Alexander Lobakin (20): net: dsa: make .flow_dissect() callback returning void net: dsa: add GRO support infrastructure net: dsa: tag_ar9331: add .flow_dissect() callback net: dsa: tag_ar9331: split out common tag accessors net: dsa: tag_ar9331: add GRO callbacks net: dsa: tag_gswip: fix typo in tag name net: dsa: tag_gswip: switch to bitfield helpers net: dsa: tag_gswip: add .flow_dissect() callback net: dsa: tag_gswip: split out common tag accessors net: dsa: tag_gswip: add GRO callbacks net: dsa: tag_lan9303: add .flow_dissect() callback net: dsa: tag_lan9303: split out common tag accessors net: dsa: tag_lan9303: add GRO callbacks net: dsa: tag_mtk: split out common tag accessors net: dsa: tag_mtk: add GRO callbacks net: dsa: tag_qca: fix doubled Tx statistics net: dsa: tag_qca: switch to bitfield helpers net: dsa: tag_qca: split out common tag accessors net: dsa: tag_qca: add GRO callbacks net: core: add (unlikely) DSA support in napi_gro_frags() include/net/dsa.h | 10 ++- net/core/dev.c | 11 ++- net/core/flow_dissector.c | 8 +- net/dsa/dsa.c | 43 +++++++++- net/dsa/dsa2.c | 1 + net/dsa/tag_ar9331.c | 139 ++++++++++++++++++++++++++----- net/dsa/tag_dsa.c | 5 +- net/dsa/tag_edsa.c | 5 +- net/dsa/tag_gswip.c | 126 +++++++++++++++++++++++----- net/dsa/tag_lan9303.c | 139 ++++++++++++++++++++++++++----- net/dsa/tag_mtk.c | 115 +++++++++++++++++++++----- net/dsa/tag_qca.c | 167 ++++++++++++++++++++++++++++---------- 12 files changed, 629 insertions(+), 140 deletions(-)