Re: [Intel-wired-lan] [next-queue 06/10] ixgbe: restore offloaded SAs after a reset

On 12/7/2017 9:16 AM, Alexander Duyck wrote:

On Wed, Dec 6, 2017 at 9:43 PM, Shannon Nelson
[off-list ref] wrote:

quoted

On 12/5/2017 9:30 AM, Alexander Duyck wrote:

quoted

On Mon, Dec 4, 2017 at 9:35 PM, Shannon Nelson
[off-list ref] wrote:

quoted

On a chip reset most of the table contents are lost, so must be

<snip>

quoted

quoted

quoted

+       /* reload the IP addrs */
+       for (i = 0; i < IXGBE_IPSEC_MAX_RX_IP_COUNT; i++) {
+               struct rx_ip_sa *ipsa = &ipsec->ip_tbl[i];
+
+               if (ipsa->used)
+                       ixgbe_ipsec_set_rx_ip(hw, i, ipsa->ipaddr);
+               else
+                       ixgbe_ipsec_set_rx_ip(hw, i, zbuf);

If we are doing a restore do we actually need to write the zero
values? If we did a reset I thought you had a function that was going
through and zeroing everything out. If so this now becomes redundant.

Currently ixgbe_ipsec_clear_hw_tables() only gets run at at probe.  It
should probably get run at remove as well.  Doing this is a bit of safety
paranoia, and making sure the CAM memory structures that don't get cleared
on reset have exactly what I expect in them.

You might just move ixgbe_ipsec_clear_hw_tables into the rest logic
itself. Then it covers all cases where you would be resetting the
hardware and expecting a consistent state. It will mean writing some
registers twice during the reset but it is probably better just to
make certain everything stays in a known good state after a reset.

If it is a small number, e.g. 10 or 20, then you may be right.  However, given we have table space for 2k different SAs, at 6 writes per Tx SA and 10 writes per Rx SA, plus 128 IP address with 4 writes each, we are already looking at 17K writes already to be sure the tables are clean.

Unfortunately, I don't really know what a "typical" case will be, so I don't know how many SA we may be offloading at any one time.  But in a busy cloud support server, we might have nearly full tables.  If we do the full clean first, then have to fill all the tables, we're now looking at up to 35k writes slowing down the reset process.

I'd rather keep it to the constant 17K writes for now, and look later at using the VALID bit in the IPSRXMOD to see if we can at least cut down on the Rx writes.

sln