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

["Ananyev, Konstantin" <konstantin.ananyev@intel.com>]

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