> > > > > > > > > Right now we are targeting crypto_cn10k PMD and ipsec-secgw event > > > > mode to support vectorization. > > > Is there a way to test this? When can be dataplane changes expected? > > > > > If the spec looks okay, support in s/w crypto adapter and other h/w PMDs can > > be added by respective maintainers. Currently, we are adding library change, > > support for one PMD and an application to test the feature. Feature is > > exposed > > with capability flag to not break existing functionality. > Got it. How do I test this feature without data plane changes?
Hi @Gujjar, Abhinandan S > If there is a way to test this, please let me know. Dataplane changes can be tested on the cn10k platform. This feature is a hardware assisted feature. > This design is right now tested for cn10k, I am not sure this works for sw > adapter. SW driver support is not added in this series as in order to accept a API change, one would need, 1)API spec 2)One of the driver 3)Test application to exercise the API. It is a similar case for all ethdev, rte_flow features etc. Community can add SW driver support just like any other subsystem APIs. Also, The proposed library changes don't differentiate between SW & HW PMDs. The proposed changes are exposed with a capability flag and so SW crypto adapter will not have any perf impact. > I need to have perf data with and without vectorization support to approve. On the cn10k platform, we see nearly 2.5x performance with vectorization. Eth rx adapter already supports vectorization and this spec change is in line with that. Also IPsec gateway update to exercise these APIs. See http://patches.dpdk.org/project/dpdk/patch/20220804103626.102688-6-vfia...@marvell.com/ Command to test on drivers which have this functionality. ./dpdk-ipsec-secgw -c 0xff0000 -a 0002:01:00.1 -a 0002:20:00.1 -a 0002:1e:00.0 -- -P -p 0x1 -P --transfer-mode event -l --event-schedule-type parallel --desc-nb 8192 --event-vector -f simple.conf sample.conf sp ipv4 out esp protect 19 pri 1 dst 192.18.0.0/32 sport 0:65535 dport 0:65535 sa out 19 aead_algo aes-128-gcm aead_key 73:69:78:74:65:65:6e:62:79:74:65:73:20:6b:65:79:64:70:64:6b mode ipv4-tunnel src 2.1.1.1 dst 1.1.1.1 type lookaside-protocol-offload port_id 0 neigh port 0 d0:37:45:02:b0:d3 rt ipv4 dst 1.1.0.0/16 port 0 In order to make forward progress and merge patch in RC1, I would request 1)Review the API specific patch(eventdev: introduce event cryptodev vector type), If spec needs to be changed to adapt any other driver(SW or HW) then the author should address that. 2)If you think, API usage is not enough with dpdk-ipsec-secgw application, I think, author should update the test-eventdev application to support the new mode.Which can be merged after RC1 as it is a test application change. Let us know what you think to make forward progress.
