On 12/7/2017 9:16 AM, Alexander Duyck wrote:
On Wed, Dec 6, 2017 at 9:43 PM, Shannon Nelson
<shannon.nel...@oracle.com> wrote:
On 12/5/2017 9:30 AM, Alexander Duyck wrote:
On Mon, Dec 4, 2017 at 9:35 PM, Shannon Nelson
<shannon.nel...@oracle.com> wrote:
On a chip reset most of the table contents are lost, so must be
<snip>
+ /* 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
