So what do you think - would you like me to clean up my DPDK hack a little and propose a change to support different external buf_addrs for src/dest or did you have something else in mind?
Also, it look like I ran into a case where a data buffer of > 32K (the next increment I tried was 64K) seems to not generate an error but also not encrypt the data. Would be good to know if that's a real limitation or not, for not I've worked around it in the calling code by breaking things up so that any single crypto op is 32K or less. Thanks Paul -----Original Message----- From: Luse, Paul E Sent: Tuesday, March 13, 2018 12:28 PM To: De Lara Guarch, Pablo <pablo.de.lara.gua...@intel.com>; Thomas Monjalon <tho...@monjalon.net> Cc: dev@dpdk.org; Doherty, Declan <declan.dohe...@intel.com>; Harris, James R <james.r.har...@intel.com>; Verkamp, Daniel <daniel.verk...@intel.com> Subject: RE: [dpdk-dev] Question on AESNI PMD Hi Pablo, Thanks for the reply. Wrt your question " Do you mean src and dst using different containers (non mbufs), or using mbufs which data is pointing at another location?" optimally, for storage use cases, something other than m_bufs would be great as right now I only use the buf_addr and userdata fields which sorta answers your question I guess :) Assuming m_bufs is a given for now, I'd like to use one m_buf to describe a src location that I allocate on my own and assign and a separate m_buf for a separate destination buffer that I also allocate on my own. That's what I'm doing now, with a small hack to the function I mention below, and it seems to be working good. Thanks! Pau -----Original Message----- From: De Lara Guarch, Pablo Sent: Tuesday, March 13, 2018 12:19 PM To: Luse, Paul E <paul.e.l...@intel.com>; Thomas Monjalon <tho...@monjalon.net> Cc: dev@dpdk.org; Doherty, Declan <declan.dohe...@intel.com> Subject: RE: [dpdk-dev] Question on AESNI PMD Hi Paul, Apologies for the delay. Answers inline. > -----Original Message----- > From: Luse, Paul E > Sent: Tuesday, March 13, 2018 2:16 PM > To: Thomas Monjalon <tho...@monjalon.net> > Cc: dev@dpdk.org; De Lara Guarch, Pablo > <pablo.de.lara.gua...@intel.com>; Doherty, Declan > <declan.dohe...@intel.com> > Subject: RE: [dpdk-dev] Question on AESNI PMD > > Any thoughts on this? > > Thanks, > Paul > > -----Original Message----- > From: Thomas Monjalon [mailto:tho...@monjalon.net] > Sent: Friday, March 9, 2018 3:36 PM > To: Luse, Paul E <paul.e.l...@intel.com> > Cc: dev@dpdk.org; De Lara Guarch, Pablo > <pablo.de.lara.gua...@intel.com>; Doherty, Declan > <declan.dohe...@intel.com> > Subject: Re: [dpdk-dev] Question on AESNI PMD > > Cc Declan and Pablo, the maintainers > > 09/03/2018 23:08, Luse, Paul E: > > Hi, > > > > I'm working on an SPDK module that uses the DPDK cryptodev > framework, initially I'm using the AESNI PMD and have a few questions. > in the doc it says that only in-place is supported however I see code > in > set_mb_job_params() just after the comment "Mutable crypto operation > parameters" it appears to support a separate src and dst m_buf so > curious about that. > > > > For my use case (storage) I'm using external data buffers so I can't > > use > that code anyways but I was able to make some minor changes and am > able to pass in different src and dst m_bufs that point to my own data > buffers (not in the packet) and it seems to be working fine. > > > > So my 2 questions are: > > > > (1) is the documented in-place limitation simply not correct? You are right, it looks like it is not correct. I need to make sure if the feature is fully supported and we can remove the limitation. > > > > (2) would there be any upstream interest in supporting a patch that > enables m_bufs using external data buffers for src and dst? Do you mean src and dst using different containers (non mbufs), or using mbufs which data is pointing at another location? The first would impact all PMDs and would introduce complexity (plus that would mean an API breakage), that might be unnecessary, whereas the second one is possible to do it from an application point of view (without changing the API). Thanks, Pablo > > > > Thanks! > > Paul > > > >
