| Message ID | 20210313113645.5949-1-alobakin@pm.me (mailing list archive) |
|---|---|
| Headers | show |
| Series | skbuff: micro-optimize flow dissection | expand |
From: Alexander Lobakin <alobakin@pm.me> Date: Sat, 13 Mar 2021 11:37:03 +0000 > This little number makes all of the flow dissection functions take > raw input data pointer as const (1-5) and shuffles the branches in > __skb_header_pointer() according to their hit probability. > > The result is +20 Mbps per flow/core with one Flow Dissector pass > per packet. This affects RPS (with software hashing), drivers that > use eth_get_headlen() on their Rx path and so on. > > Since v1 [0]: > - rebase on top of the latest net-next. This was super-weird, but > I double-checked that the series applies with no conflicts, and > then on Patchwork it didn't; Still failing on Patchwork. I rebased it ten thousand times, rebuilt the patches manually, tried previous stable Git version and the latest CVS snapshot, and always got the same series that successfully applies to next-next. Can you please take a look? > - no other changes. > > [0] https://lore.kernel.org/netdev/20210312194538.337504-1-alobakin@pm.me > > Alexander Lobakin (6): > flow_dissector: constify bpf_flow_dissector's data pointers > skbuff: make __skb_header_pointer()'s data argument const > flow_dissector: constify raw input @data argument > linux/etherdevice.h: misc trailing whitespace cleanup > ethernet: constify eth_get_headlen()'s @data argument > skbuff: micro-optimize {,__}skb_header_pointer() > > include/linux/etherdevice.h | 4 ++-- > include/linux/skbuff.h | 26 +++++++++++------------ > include/net/flow_dissector.h | 6 +++--- > net/core/flow_dissector.c | 41 +++++++++++++++++++----------------- > net/ethernet/eth.c | 2 +- > 5 files changed, 40 insertions(+), 39 deletions(-) > > -- > 2.30.2 Thanks, Al
None of these apply to net-next as per the patchwork automated checks. Any idea why? Thanks.
From: David Miller <davem@davemloft.net> Date: Sat, 13 Mar 2021 18:10:00 -0800 (PST) > None of these apply to net-next as per the patchwork automated checks. Any idea why? No unfortunately. That'why I sent a follow-up mail. All of them successfully apply to pure net-next on my machine. Can it be a Git version conflict? I use 2.30.2, but also tried 2.30.1 and the latest development snapshot, and in either case they got applied with no problems. I could have more clue if NIPA provided more detailed log, but didn't find any. And apply_patches stage doesn't seem to be present on NIPA GitHub repo, so I couldn't reproduce it 1:1. I can try again on Monday, not sure if it will help. I also sent another series yesterday, and it has 15 green lights on Patchwork, so this problem seems to take place only with this particular series. > Thanks. Thanks, Al
This little number makes all of the flow dissection functions take raw input data pointer as const (1-5) and shuffles the branches in __skb_header_pointer() according to their hit probability. The result is +20 Mbps per flow/core with one Flow Dissector pass per packet. This affects RPS (with software hashing), drivers that use eth_get_headlen() on their Rx path and so on. Since v1 [0]: - rebase on top of the latest net-next. This was super-weird, but I double-checked that the series applies with no conflicts, and then on Patchwork it didn't; - no other changes. [0] https://lore.kernel.org/netdev/20210312194538.337504-1-alobakin@pm.me Alexander Lobakin (6): flow_dissector: constify bpf_flow_dissector's data pointers skbuff: make __skb_header_pointer()'s data argument const flow_dissector: constify raw input @data argument linux/etherdevice.h: misc trailing whitespace cleanup ethernet: constify eth_get_headlen()'s @data argument skbuff: micro-optimize {,__}skb_header_pointer() include/linux/etherdevice.h | 4 ++-- include/linux/skbuff.h | 26 +++++++++++------------ include/net/flow_dissector.h | 6 +++--- net/core/flow_dissector.c | 41 +++++++++++++++++++----------------- net/ethernet/eth.c | 2 +- 5 files changed, 40 insertions(+), 39 deletions(-) -- 2.30.2