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

I didn't talk about forking.
I talked about something like that - keep all code in examples/ipsec-secgw
Probably move event/poll specific code into
examples/ipsec-secgw/poll, examples/ipsec-secgw/event.
Make changes in Makefile, meson.build to generate 2 binaries.
But ok, one extra event-mode specific option doesn't seem that much.
Let's try to keep unified binary and see how it goes.
Konstantin