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.

>
> >
> >
> >
> > >
> > > > 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