On 8/16/2018 2:36 PM, Shannon Nelson wrote:
On 8/16/2018 2:15 PM, Alexander Duyck wrote:
On Tue, Aug 14, 2018 at 10:10 AM Shannon Nelson
<shannon.nel...@oracle.com> wrote:

On 8/14/2018 8:30 AM, Alexander Duyck wrote:
On Mon, Aug 13, 2018 at 11:43 AM Shannon Nelson
<shannon.nel...@oracle.com> wrote:

This set of patches implements IPsec hardware offload for VF devices in
Intel's 10Gbe x540 family of Ethernet devices.

[...]


So the one question I would have about this patch set is what happens
if you are setting up a ipsec connection between the PF and one of the
VFs on the same port/function? Do the ipsec offloads get translated
across the Tx loopback or do they end up causing issues? Specifically
I would be interested in seeing the results of a test either between
two VFs, or the PF and one of the VFs on the same port.

- Alex


There is definitely something funky in the internal switch connection,
as messages going from PF to VF with an offloaded encryption don't seem
to get received by the VF, at least when in a VEB setup.  If I only set
up offloads on the Rx on both PF and VF, and don't offload the Tx, then
things work.

I don't have a setup to test this, but I suspect that in a VEPA
configuration, with packets going out to the switch and turned around
back in, the Tx encryption offload would happen as expected.

sln

We should probably look at adding at least one patch to the set then
that disables IPsec Tx offload if SR-IOV is enabled with VEB so that
we don't end up breaking connections should a VF be migrated from a
remote system to a local one that it is connected to.

- Alex


The problem with this is that someone could set up an IPsec connection on the PF for Tx and Rx use, then set num_vfs, start some VFs, and we still can end up in the same place.  I don't think we want to disallow all Tx IPsec offload.

Maybe we can catch it in ixgbe_ipsec_offload_ok()?  If it can find that the dest mac is on the internal switch, perhaps it can NAK the Tx offload?  That would force the XFRM xmit code to do a regular SW encrypt before sending the packet.  I'll look into this.

sln

This would be a great idea, but the xdo_state_offload_ok() callback happens in the network stack before routing has happened, so there is no mac address yet in the skb. We may be stuck with NAKing *all* Tx offloads when num_vfs != 0. It works, and it is better than no offload at all, but it sure harshes the vibe. Blech.

sln

Reply via email to