Re: [dpdk-dev] [PATCH] ethdev: add packet integrity checks

[Ori Kam <orika@nvidia.com>]

Hi Jerin & Ajit

> -----Original Message-----
> From: Ajit Khaparde <ajit.khaparde@broadcom.com>
> Sent: Sunday, April 11, 2021 7:13 AM
> 
> On Thu, Apr 8, 2021 at 12:44 AM Jerin Jacob <jerinjacobk@gmail.com> wrote:
> >
> > On Thu, Apr 8, 2021 at 3:45 AM Ori Kam <orika@nvidia.com> wrote:
> > >
> > > Hi Jerin,
> > >
> > > > -----Original Message-----
> > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > Subject: Re: [dpdk-dev] [PATCH] ethdev: add packet integrity checks
> > > >
> > > > On Wed, Apr 7, 2021 at 4:02 PM Ori Kam <orika@nvidia.com> wrote:
> > > > >
> > > > > Hi Jerin,
> > > >
> > > > Hi Ori,
> > > >
> > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > > > Sent: Tuesday, April 6, 2021 10:40 AM
> > > > > > To: Ori Kam <orika@nvidia.com>
> > > > > > Subject: Re: [dpdk-dev] [PATCH] ethdev: add packet integrity checks
> > > > > >
> > > > > > On Mon, Apr 5, 2021 at 11:35 PM Ori Kam <orika@nvidia.com>
> wrote:
> > > > > > >
> > > > > > > Currently, DPDK application can offload the checksum check,
> > > > > > > and report it in the mbuf.
> > > > > > >
> > > > > > > However, as more and more applications are offloading some or all
> > > > > > > logic and action to the HW, there is a need to check the packet
> > > > > > > integrity so the right decision can be taken.
> > > > > > >
> > > > > > > The application logic can be positive meaning if the packet is
> > > > > > > valid jump / do  actions, or negative if packet is not valid
> > > > > > > jump to SW / do actions (like drop)  a, and add default flow
> > > > > > > (match all in low priority) that will direct the miss packet
> > > > > > > to the miss path.
> > > > > > >
> > > > > > > Since currenlty rte_flow works in positive way the assumtion is
> > > > > > > that the postive way will be the common way in this case also.
> > > > > > >
> > > > > > > When thinking what is the best API to implement such feature,
> > > > > > > we need to considure the following (in no specific order):
> > > > > > > 1. API breakage.
> > > > > > > 2. Simplicity.
> > > > > > > 3. Performance.
> > > > > > > 4. HW capabilities.
> > > > > > > 5. rte_flow limitation.
> > > > > > > 6. Flexability.
> > > > > >
> > > > > >
> > > > > > Alteast in Marvell HW integrity checks are functions of the Ethdev Rx
> > > > > > queue attribute.
> > > > > > Not sure about other Vendor HW.
> > > > >
> > > > > I'm not sure what do you mean?
> > > >
> > > > What I meant is, What will be the preferred way to configure the feature?
> > > > ie. Is it as ethdev Rx offload or rte_flow?
> > > >
> > > > I think, in order to decide that, we need to know, how most of the
> > > > other HW express this feature?
> > > >
> > >
> > > As  I see it both ways could be used,
> > > Maybe even by the same app,
> > >
> > > One flow is to notify the application when it sees the packet
> > > (RX offload) and one is to use as an item to route the packet
> > > when using rte_flow.
> > >
> > > Maybe I'm missing something, on your suggestion how will
> > > application route the packets? Or it will just receive them with flags
> > > on the RX queue?
> >
> > Just receive them with flags on the Rx queue, in order to avoid
> > duplicating features
> > in multiple places.
> I think this is more reasonable and simpler.
> Especially when I read the discussion further in the thread between
> Andrew and Ori.
> 

Ajit, I'm sorry but I'm not sure I understand if you like better the suggested approach,
or the RX one?

In any case those are two different cases, one is for the application and one is for 
offloaded routing.

Best,
Ori

> >
> > >
> > >
> > >
> > > >
> > > > > This is the idea of the patch, to allow application to route the packet
> > > > > before getting to the Rx,
> > > > > In any case all items support is dependent on HW capabilities.
> > > >
> > > >
> > > >
> > > >
> > >
> > > Best,
> > > Ori