> -----Original Message-----
> From: Radu Nicolau <radu.nico...@intel.com>
> Sent: Tuesday, October 24, 2023 6:23 PM
> To: Marchand, David <david.march...@redhat.com>
> Cc: Wu, Jingjing <jingjing...@intel.com>; Xing, Beilei
> <beilei.x...@intel.com>;
> dev@dpdk.org; sta...@dpdk.org
> Subject: Re: [PATCH] net/iavf: fix IAVF_TX_OFFLOAD_MASK definition
>
>
> On 24-Oct-23 10:49 AM, David Marchand wrote:
> > On Tue, Oct 24, 2023 at 11:13 AM Radu Nicolau <radu.nico...@intel.com>
> wrote:
> >> IAVF_TX_OFFLOAD_MASK definition contained
> RTE_ETH_TX_OFFLOAD_SECURITY
> >> instead of RTE_MBUF_F_TX_SEC_OFFLOAD.
> >>
> >> Fixes: 6bc987ecb860 ("net/iavf: support IPsec inline crypto")
> >> Cc: sta...@dpdk.org
> >>
> >> Signed-off-by: Radu Nicolau <radu.nico...@intel.com>
> > Something is not clear to me.
> > How was the IPsec inline crypto feature supposed to work with this
> > driver so far?
> >
> > Any packet with the RTE_MBUF_F_TX_SEC_OFFLOAD flag should have been
> > refused in iavf_prep_pkts.
> >
> It worked because the IPsec sample app doesn't call rte_eth_tx_prepare, and
> from what I can see no other sample app does.
To keep consistent, its better to refine the IAVF_TX_OFFLOAD_NOTSUP_MASK
definition.
