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

[Ori Kam]

Hi Jerin,

> -----Original Message-----
> From: Jerin Jacob <jerinjacobk at gmail.com>
> Subject: Re: [dpdk-dev] [PATCH] ethdev: add packet integrity checks
> 
> On Wed, Apr 7, 2021 at 4:02 PM Ori Kam <orika at nvidia.com> wrote:
> >
> > Hi Jerin,
> 
> Hi Ori,
> 
> 
> >
> > > -----Original Message-----
> > > From: Jerin Jacob <jerinjacobk at gmail.com>
> > > Sent: Tuesday, April 6, 2021 10:40 AM
> > > To: Ori Kam <orika at nvidia.com>
> > > Subject: Re: [dpdk-dev] [PATCH] ethdev: add packet integrity checks
> > >
> > > On Mon, Apr 5, 2021 at 11:35 PM Ori Kam <orika at 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?
 


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