On Tue, May 21, 2019 at 10:55 AM Lennart Sorensen
<lsore...@csclub.uwaterloo.ca> wrote:
>
> On Tue, May 21, 2019 at 09:51:33AM -0700, Alexander Duyck wrote:
> > I think we need to narrow this down a bit more. Let's try forcing the
> > lookup table all to one value and see if traffic is still going to
> > queue 0.
> >
> > Specifically what we need to is run the following command to try and
> > force all RSS traffic to queue 8, you can verify the result with
> > "ethtool -x":
> > ethtool -X <iface> weight 0 0 0 0 0 0 0 0 1
> >
> > If that works and the IPSec traffic goes to queue 8 then we are likely
> > looking at some sort of input issue, either in the parsing or the
> > population of things like the input mask that we can then debug
> > further.
> >
> > If traffic still goes to queue 0 then that tells us the output of the
> > RSS hash and lookup table are being ignored, this would imply either
> > some other filter is rerouting the traffic or is directing us to limit
> > the queue index to 0 bits.
>
> # ethtool -x eth2
> RX flow hash indirection table for eth2 with 12 RX ring(s):
> 0: 7 7 7 7 7 7 7 7
> 8: 7 7 7 7 7 7 7 7
> 16: 7 7 7 7 7 7 7 7
> 24: 7 7 7 7 7 7 7 7
> 32: 7 7 7 7 7 7 7 7
> ...
> 472: 7 7 7 7 7 7 7 7
> 480: 7 7 7 7 7 7 7 7
> 488: 7 7 7 7 7 7 7 7
> 496: 7 7 7 7 7 7 7 7
> 504: 7 7 7 7 7 7 7 7
> RSS hash key:
> 0b:1f:ae:ed:60:04:7d:e5:8a:2b:43:3f:1d:ee:6c:99:89:29:94:b0:25:db:c7:4b:fa:da:4d:3f:e8:cc:bc:00:ad:32:01:d6:1c:30:3f:f8:79:3e:f4:48:04:1f:51:d2:5a:39:f0:90
> root@ECA:~# ethtool --show-priv-flags eth2
> Private flags for eth2:
> MFP : off
> LinkPolling : off
> flow-director-atr: off
> veb-stats : off
> hw-atr-eviction : on
> legacy-rx : off
>
> All ipsec packets are still hitting queue 0.
>
> Seems it is completely ignoring RSS for these packets. That is
> impressively weird.
>
> --
> Len Sorensen
So we are either using 0 bits of the LUT or we are just not performing
hashing because this is somehow being parsed into a type that doesn't
support it.
I have attached 2 more patches we can test. The first enables hashing
on what are called "OAM" packets, The thing is we shouldn't be
identifying these packets as "OAM", Operations Administration &
Management, as normally it would have to be recognized as a tunnel
first and then have a specific flag set in either the GENEVE or
VXLAN-GPE header. The second patch will dump the contents of the
HREGION registers. They should all be 0, however I thought it best to
dump the contents and verify that since I know that these registers
can be used to change the traffic class of a given packet type and if
we are encountering that it might be moving it to an uninitialized TC
which would be using queue offset 0 with 0 bits of the LUT.
These last 2 patches would pretty much eliminate the entire RSS
subsystem. If we don't see HREGION values set and the OAM flags have
no effect I can only assume there is something going on with the
parser in the NIC since it isn't recognizing the packet type.
Thanks.
- Alex
i40e: Enable OAM flag tunnel hashing
From: Alexander Duyck <alexander.h.du...@linux.intel.com>
Add support for hashing packet types 26 and 27 on X722 adapters. The
default input set is supposed to be source outer UDP and VNI. For now all I
care about is enabling hashing on this to see if we can get ESP traffic to
not hit queue 0 for everything.
---
drivers/net/ethernet/intel/i40e/i40e_txrx.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.h b/drivers/net/ethernet/intel/i40e/i40e_txrx.h
index 100e92d2982f..ad3e16e8cd7a 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_txrx.h
+++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.h
@@ -95,7 +95,8 @@ enum i40e_dyn_idx_t {
BIT_ULL(I40E_FILTER_PCTYPE_NONF_MULTICAST_IPV4_UDP) | \
BIT_ULL(I40E_FILTER_PCTYPE_NONF_IPV6_TCP_SYN_NO_ACK) | \
BIT_ULL(I40E_FILTER_PCTYPE_NONF_UNICAST_IPV6_UDP) | \
- BIT_ULL(I40E_FILTER_PCTYPE_NONF_MULTICAST_IPV6_UDP))
+ BIT_ULL(I40E_FILTER_PCTYPE_NONF_MULTICAST_IPV6_UDP) | \
+ BIT_ULL(26) | BIT_ULL(27)) /* Added bits for tunnel OAM */
#define i40e_pf_get_default_rss_hena(pf) \
(((pf)->hw_features & I40E_HW_MULTIPLE_TCP_UDP_RSS_PCTYPE) ? \
i40e: Dump HREGION entries
From: Alexander Duyck <alexander.h.du...@linux.intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 320562b39686..370f66df4e4f 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -11094,6 +11094,14 @@ static int i40e_pf_config_rss(struct i40e_pf *pf)
u64 hena;
int ret;
+ /* These should all be 0, dump them to verify they are */
+ for (ret = 8; ret--;) {
+ reg_val = i40e_read_rx_ctl(hw, I40E_PFQF_HREGION(ret));
+
+ dev_info(&pf->pdev->dev,
+ "PFQF_HREGION[%d]: 0x%08x\n", ret, reg_val);
+ }
+
/* By default we enable TCP/UDP with IPv4/IPv6 ptypes */
hena = (u64)i40e_read_rx_ctl(hw, I40E_PFQF_HENA(0)) |
((u64)i40e_read_rx_ctl(hw, I40E_PFQF_HENA(1)) << 32);
