Hi Konstantin, Please see inline.
Thanks, Anoob > -----Original Message----- > From: Ananyev, Konstantin <konstantin.anan...@intel.com> > Sent: Monday, January 6, 2020 10:21 PM > To: Anoob Joseph <ano...@marvell.com>; Akhil Goyal <akhil.go...@nxp.com>; > Nicolau, Radu <radu.nico...@intel.com>; Thomas Monjalon > <tho...@monjalon.net> > Cc: Lukas Bartosik <lbarto...@marvell.com>; Jerin Jacob Kollanukkaran > <jer...@marvell.com>; Narayana Prasad Raju Athreya > <pathr...@marvell.com>; Ankur Dwivedi <adwiv...@marvell.com>; Archana > Muniganti <march...@marvell.com>; Tejasree Kondoj > <ktejas...@marvell.com>; Vamsi Krishna Attunuru <vattun...@marvell.com>; > dev@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.
