[dpdk-dev] [PATCH 09/14] examples/ipsec-secgw: add eventmode to ipsec-secgw

[Anoob Joseph]

Hi Konstantin,

Please see inline.

Thanks,
Anoob

> -----Original Message-----
> From: Ananyev, Konstantin <konstantin.ananyev at intel.com>
> Sent: Monday, January 6, 2020 10:21 PM
> To: Anoob Joseph <anoobj at marvell.com>; Akhil Goyal <akhil.goyal at nxp.com>;
> Nicolau, Radu <radu.nicolau at intel.com>; Thomas Monjalon
> <thomas at monjalon.net>
> Cc: Lukas Bartosik <lbartosik at marvell.com>; Jerin Jacob Kollanukkaran
> <jerinj at marvell.com>; Narayana Prasad Raju Athreya
> <pathreya at marvell.com>; Ankur Dwivedi <adwivedi at marvell.com>; Archana
> Muniganti <marchana at marvell.com>; Tejasree Kondoj
> <ktejasree at marvell.com>; Vamsi Krishna Attunuru <vattunuru at marvell.com>;
> dev at dpdk.org
> Subject: [EXT] RE: [PATCH 09/14] examples/ipsec-secgw: add eventmode to
> ipsec-secgw
> 
> External Email
> 
> ----------------------------------------------------------------------
> > > > Add eventmode support to ipsec-secgw. This uses event helper to
> > > > setup and use the eventmode capabilities. Add driver inbound worker.
> > > >
> > > > Example command:
> > > > ./ipsec-secgw -c 0x1 -w 0002:02:00.0,ipsec_in_max_spi=100 -w
> > > > 0002:07:00.0  -w 0002:0e:00.0 -w 0002:10:00.1 -- -P -p 0x3 -u 0x1
> > > > --config "(0,0,0),(1,0,0)" -f a-aes-gcm-msa.cfg --transfer-mode 1
> > > > --schedule-type 2 --process-mode drv --process-dir in
> > >
> > > As  I can see new event mode is totally orthogonal to the existing poll mode.
> > > Event mode has it is own data-path, and it doesn't reuse any part of
> > > poll- mode data-path code.
> > > Plus in event mode many poll-mode options:
> > > libirary/legacy mode, fragment/reassemble, replay-window, ESN,
> > > fall-back session, etc.
> > > are simply ignored.
> >
> > [Anoob] The features are not supported with the initial version. But
> > the features are equally applicable to eventmode and is planned for the future.
> Also, fragment/reassemble, replay-window, ESN, fall-back session etc are not
> applicable for non-library mode.
> 
> True, but in poll-mode library-mode support all functionality that legacy-mode
> does, plus some extra.
> Also I still hope that after perf-problems evaluation with NXP we will be able to
> safely remove legacy poll-mode.
> 
> >We can follow the
> > same logic and allow for an extra arg (which is --transfer-mode).
> >
> > > Also as I can read the current code - right now these modes can't be
> > > mixed and used together.
> > > User has to use either only event based or poll mode API/devices.
> >
> > [Anoob] Same like how we cannot mix library and non-library modes.
> >
> > >
> > > If so, then at least we need a check (and report with error exit)
> > > for these mutually exclusive option variants.
> >
> > [Anoob] Will do that.
> 
> Ok.
> 
> > > Probably even better would be to generate two separate binaries Let say:
> > > ipsec-secgw-event and ipsec-secgw-poll.
> > > We can still keep the same parent directory, makefile, common src files etc.
> > > for both.
> >
> > [Anoob] I would be inclined to not fork the current application. Do
> > you see any issues if the same binary could run in both modes. The default
> behavior would be poll mode (with existing behavior).
> 
> My main concern here that there will be over-helming number of options (some
> of which are mutually exclusive) in the same app.
> So it will be really hard to maintain and use such app.
> My thought was that it might be cleaner to have two different apps each with its
> own set of options.
> 

[Anoob] Technically event mode would need only one extra argument. The one to specify "scheduling type". The direction can be removed (discussed in another thread) and app-mode can be merged with existing single_sa mode.

And we do want the event-mode to be supporting all features supported by poll mode. Just that we will have to take it up gradually (because of the volume of code change).

Thomas had opposed the idea of forking example applications for event mode. I also agree with him there. Event-mode just establishes an alternate way to receive and send packets. Entire IPsec processing can be maintained common.