> -----Original Message----- > From: Akhil Goyal <[email protected]> > Sent: środa, 15 lipca 2020 22:16 > To: Thomas Monjalon <[email protected]>; Kusztal, ArkadiuszX > <[email protected]> > Cc: [email protected]; Trahe, Fiona <[email protected]>; > [email protected]; Anoob Joseph <[email protected]>; Somalapuram, > Amaranath <[email protected]>; Ankur Dwivedi > <[email protected]>; [email protected]; De Lara Guarch, Pablo > <[email protected]>; Nagadheeraj Rottela > <[email protected]> > Subject: RE: [PATCH v3 0/5] app: add multi process crypto application > > > > I see this application as a useful tool to test the readiness of a > > > driver to be > > used > > > in a multi process environment. If app is not a correct place to > > > host it, should it > > be > > > added in examples/multi_process/. I also suggested that in v2 but it > > > makes > > more > > > sense in app as it is a unit test application which does not have > > > any relevance > > as > > > standalone application as crypto may not be used standalone without > > > ethernet for multi process scenario. > > > My first preference was to modify l2fwd-crypto to be used as a multi > > > process > > proof > > > Application but it also make sense to have a unit test application > > > to verify > > standalone > > > crypto PMDs. > > > Open for comments from other crypto PMD owners. > > > > I agree it looks like unit tests. > > Can it be added to app/test/test_cryptodev* ? > > > > Running two instances of test application will be a challenge I guess. > If it can be done, I think all the cases covered in test app other than crypto > would be affected/tested. > > Test-crypto-perf can be a better option but it may defeat the purpose of test- > crypto-perf. > Best would be to make l2fwd-crypto compliant with multi process. > But still I am ok to have a unit test application. [Arek] - Having this as a test would be much more handy as it does not need any additional infrastructure like traffic generators. Just only crypto accelerator and can work out of the box. Just thinking primary-secondary testing was not getting enough attention by now, for example: Until patch bus/pci: fix UIO resource access from secondary process Apr 24 2020 dev->mem_resource[i].addr was not set -> so basically configuration from secondary was rather difficult without PCI BAR address. Plus having option to test queue pairs configured in different processes or checking enqueue/dequeue from different processes to one queue pair would be handy even for regression testing. > >
