[dpdk-dev] Question on AESNI PMD

[dpdk-dev] Question on AESNI PMD

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

(2) would there be any upstream interest in supporting a patch that enables m_bufs using external data buffers for src and dst?

Thanks!
Paul

Re: [dpdk-dev] Question on AESNI PMD

[Thomas Monjalon]

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?
> 
> (2) would there be any upstream interest in supporting a patch that enables m_bufs using external data buffers for src and dst?
> 
> Thanks!
> Paul

Re: [dpdk-dev] Question on AESNI PMD

[Luse, Paul E]

Any thoughts on this?

Thanks,
Paul

-----Original Message-----
From: Thomas Monjalon [mailto:thomas@monjalon.net] 
Sent: Friday, March 9, 2018 3:36 PM
To: Luse, Paul E <paul.e.luse@intel.com>
Cc: dev@dpdk.org; De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>; Doherty, Declan <declan.doherty@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?
> 
> (2) would there be any upstream interest in supporting a patch that enables m_bufs using external data buffers for src and dst?
> 
> Thanks!
> Paul

Re: [dpdk-dev] Question on AESNI PMD

[De Lara Guarch, Pablo]

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 <thomas@monjalon.net>
> Cc: dev@dpdk.org; De Lara Guarch, Pablo
> <pablo.de.lara.guarch@intel.com>; Doherty, Declan
> <declan.doherty@intel.com>
> Subject: RE: [dpdk-dev] Question on AESNI PMD
> 
> Any thoughts on this?
> 
> Thanks,
> Paul
> 
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Friday, March 9, 2018 3:36 PM
> To: Luse, Paul E <paul.e.luse@intel.com>
> Cc: dev@dpdk.org; De Lara Guarch, Pablo
> <pablo.de.lara.guarch@intel.com>; Doherty, Declan
> <declan.doherty@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
> 
> 
> 
> 

Re: [dpdk-dev] Question on AESNI PMD

[Luse, Paul E]

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.luse@intel.com>; Thomas Monjalon <thomas@monjalon.net>
Cc: dev@dpdk.org; Doherty, Declan <declan.doherty@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 <thomas@monjalon.net>
> Cc: dev@dpdk.org; De Lara Guarch, Pablo 
> <pablo.de.lara.guarch@intel.com>; Doherty, Declan 
> <declan.doherty@intel.com>
> Subject: RE: [dpdk-dev] Question on AESNI PMD
> 
> Any thoughts on this?
> 
> Thanks,
> Paul
> 
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Friday, March 9, 2018 3:36 PM
> To: Luse, Paul E <paul.e.luse@intel.com>
> Cc: dev@dpdk.org; De Lara Guarch, Pablo 
> <pablo.de.lara.guarch@intel.com>; Doherty, Declan 
> <declan.doherty@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
> 
> 
> 
> 

Re: [dpdk-dev] Question on AESNI PMD

[Luse, Paul E]

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.guarch@intel.com>; Thomas Monjalon <thomas@monjalon.net>
Cc: dev@dpdk.org; Doherty, Declan <declan.doherty@intel.com>; Harris, James R <james.r.harris@intel.com>; Verkamp, Daniel <daniel.verkamp@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.luse@intel.com>; Thomas Monjalon <thomas@monjalon.net>
Cc: dev@dpdk.org; Doherty, Declan <declan.doherty@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 <thomas@monjalon.net>
> Cc: dev@dpdk.org; De Lara Guarch, Pablo 
> <pablo.de.lara.guarch@intel.com>; Doherty, Declan 
> <declan.doherty@intel.com>
> Subject: RE: [dpdk-dev] Question on AESNI PMD
> 
> Any thoughts on this?
> 
> Thanks,
> Paul
> 
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Friday, March 9, 2018 3:36 PM
> To: Luse, Paul E <paul.e.luse@intel.com>
> Cc: dev@dpdk.org; De Lara Guarch, Pablo 
> <pablo.de.lara.guarch@intel.com>; Doherty, Declan 
> <declan.doherty@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
> 
> 
> 
> 

Re: [dpdk-dev] Question on AESNI PMD

[Luse, Paul E]

Any thoughts on this?

-----Original Message-----
From: Luse, Paul E 
Sent: Wednesday, March 14, 2018 5:43 PM
To: De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>; 'Thomas Monjalon' <thomas@monjalon.net>
Cc: 'dev@dpdk.org' <dev@dpdk.org>; Doherty, Declan <declan.doherty@intel.com>; Harris, James R <james.r.harris@intel.com>; Verkamp, Daniel <daniel.verkamp@intel.com>
Subject: RE: [dpdk-dev] Question on AESNI PMD

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.guarch@intel.com>; Thomas Monjalon <thomas@monjalon.net>
Cc: dev@dpdk.org; Doherty, Declan <declan.doherty@intel.com>; Harris, James R <james.r.harris@intel.com>; Verkamp, Daniel <daniel.verkamp@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.luse@intel.com>; Thomas Monjalon <thomas@monjalon.net>
Cc: dev@dpdk.org; Doherty, Declan <declan.doherty@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 <thomas@monjalon.net>
> Cc: dev@dpdk.org; De Lara Guarch, Pablo 
> <pablo.de.lara.guarch@intel.com>; Doherty, Declan 
> <declan.doherty@intel.com>
> Subject: RE: [dpdk-dev] Question on AESNI PMD
> 
> Any thoughts on this?
> 
> Thanks,
> Paul
> 
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Friday, March 9, 2018 3:36 PM
> To: Luse, Paul E <paul.e.luse@intel.com>
> Cc: dev@dpdk.org; De Lara Guarch, Pablo 
> <pablo.de.lara.guarch@intel.com>; Doherty, Declan 
> <declan.doherty@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
> 
> 
> 
> 

[dpdk-dev] Question on AESNI PMD

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

(2) would there be any upstream interest in supporting a patch that enables m_bufs using external data buffers for src and dst?

Thanks!
Paul