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