[dpdk-dev] Recent change to make rte_cryptodev_pmd.h internal prevents some important functionality
Hi Everyone, We use cryptodev in SPDK and included rte_cryptodev_pmd.h so that we may release qpair memory that was allocated when we called rte_cryptodev_queue_pair_setup(). We’d do so by calling the function pointer queue_pair_release() which I believe is the prescribed way to do this. The DPDK change in question is here: https://github.com/DPDK/dpdk/commit/af668035f7f492424b2e199f155690815944a8ca Question: Is there another way for us to release this memory? I’ve looked through the public API and nothing stands out. Thanks Paul
[dpdk-dev] Recent change to make rte_cryptodev_pmd.h internal prevents some important functionality
Hi Everyone, I sent this last week and haven’t heard back – apologize if I missed the response but if not here it is again… We use cryptodev in SPDK and included rte_cryptodev_pmd.h so that we may release qpair memory that was allocated when we called rte_cryptodev_queue_pair_setup(). We’d do so by calling the function pointer queue_pair_release() which I believe is the prescribed way to do this. The DPDK change in question is here: https://github.com/DPDK/dpdk/commit/af668035f7f492424b2e199f155690815944a8ca Question: Is there another way for us to release this memory? I’ve looked through the public API and nothing stands out. Thanks Paul
[dpdk-dev] Issue/Question with multi-process and CryptoDev using AESNI_MB
Hi All, I'm having an issue with the following scenario with SPDK-based applications built w/DPDK using CryptoDev in a primary/secondary process setup. Primary Process: An application that does crypto and properly initializes aesni_mb Secondary Process: An application that does not use crypto so does not initialize aesni_mb What I'm seeing: 1) Primary Process: Initializes normally 2) Secondary Process: At DPDK initialization time rte_eal_init()->rte_bus_scan()->vdev_scan() Is called in that order and then in vdev_scan() there's a block of code that sends a msg to the primary process to get device names that it's initialized so the secondary ends up adding the aesni device and initializing it. 3) Process 2: Exits but because this SPDK application did not initialize crypto, it does not call rte_vdev_uninit() so on exit gets several memory leaks from allocations made during DPDK’s initialization of aesni, for example, alloc_mb_mgr() It seems as though the secondary side should be tearing down aesni_mb assuming that it was not the one who called rte_cryptodev_pmd_create() but I am fairly new to these code sequences so am looking for some advice on what makes sense here to address the issue. thanks Paul
[dpdk-dev] Issue/Question with multi-process and CryptoDev using AESNI_MB
Hi All, I'm having an issue with the following scenario with SPDK-based applications built w/DPDK using CryptoDev in a primary/secondary process setup. Primary Process: An application that does crypto and properly initializes aesni_mb Secondary Process: An application that does not use crypto so does not initialize aesni_mb What I'm seeing: 1) Primary Process: Initializes normally 2) Secondary Process: At DPDK initialization time rte_eal_init()->rte_bus_scan()->vdev_scan() Is called in that order and then in vdev_scan() there's a block of code that sends a msg to the primary process to get device names that it's initialized so the secondary ends up adding the aesni device and initializing it. 3) Secondary Process: Exits but because this SPDK application did not initialize crypto, it does not call rte_vdev_uninit() so on exit gets several memory leaks from allocations made during DPDK’s initialization of aesni, for example, alloc_mb_mgr() It seems as though the secondary side should be tearing down aesni_mb assuming that it was not the one who called rte_cryptodev_pmd_create() but I am fairly new to these code sequences so am looking for some advice on what makes sense here to address the issue. thanks Paul
Re: [dpdk-dev] mail to ack
-Original Message- From: Trahe, Fiona Sent: Tuesday, December 18, 2018 7:43 AM To: Stephen Hemminger Cc: dev@dpdk.org; akhil.go...@nxp.com; Jozwiak, TomaszX ; shally.ve...@caviumnetworks.com; ashish.gu...@caviumnetworks.com; Daly, Lee ; Luse, Paul E ; Trahe, Fiona Subject: RE: [dpdk-dev] [PATCH] compressdev: add feature flag to specify where processing is done Hi Stephen //snip// > > > Subject: Re: [dpdk-dev] [PATCH] compressdev: add feature flag to > > > specify where processing is done > > > > > > On Tue, 20 Nov 2018 01:39:48 + Fiona Trahe > > > wrote: > > > > > > > A new device feature flag, RTE_COMPDEV_FF_SW_OP_DONE_IN_DEQUEUE > > > > is added. A PMD which processes operations using a software > > > > acceleration engine should set this if the bulk of the > > > > processing is done during the dequeue. It should leave it > > > > cleared if the bulk of the processing is done during the enqueue > > > > (default). > > > > An application may find this useful for tuning. > > > > > > > > Signed-off-by: Fiona Trahe > > > > > > What application? or is this "if we build it they will come?" > > [Fiona] Our storage team asked for this, so not quite. > > Seems like it might by generically useful, so a bit of the latter > > too :) Would you prefer I removed that line? > > Hopefully, there would be one or more open source projects using the API. > I just did a survey of DPDK an 1/3 of it is never used by any open > source project. Hate to see more dead code and special cases created. > > At least, some example code in examples would help. Something like a > simple in memory compressed storage server using a network API > (SMB?/SSH?/FTP?) [Fiona] There is no compressdev sample app yet. However I've double-checked with the SPDK team, they're currently integrating compressdev and intend to push a patch to SPDK - a storage open-source project - using this flag. Acked-by: Paul Luse
[dpdk-dev] [PATCH] compressdev: add feature flag to specify where processing is done
Resend wrong subject -Original Message- From: Trahe, Fiona Sent: Tuesday, December 18, 2018 7:43 AM To: Stephen Hemminger Cc: dev@dpdk.org; akhil.go...@nxp.com; Jozwiak, TomaszX ; shally.ve...@caviumnetworks.com; ashish.gu...@caviumnetworks.com; Daly, Lee ; Luse, Paul E ; Trahe, Fiona Subject: RE: [dpdk-dev] [PATCH] compressdev: add feature flag to specify where processing is done Hi Stephen //snip// > > > Subject: Re: [dpdk-dev] [PATCH] compressdev: add feature flag to > > > specify where processing is done > > > > > > On Tue, 20 Nov 2018 01:39:48 + Fiona Trahe > > > wrote: > > > > > > > A new device feature flag, RTE_COMPDEV_FF_SW_OP_DONE_IN_DEQUEUE > > > > is added. A PMD which processes operations using a software > > > > acceleration engine should set this if the bulk of the > > > > processing is done during the dequeue. It should leave it > > > > cleared if the bulk of the processing is done during the enqueue > > > > (default). > > > > An application may find this useful for tuning. > > > > > > > > Signed-off-by: Fiona Trahe > > > > > > What application? or is this "if we build it they will come?" > > [Fiona] Our storage team asked for this, so not quite. > > Seems like it might by generically useful, so a bit of the latter > > too :) Would you prefer I removed that line? > > Hopefully, there would be one or more open source projects using the API. > I just did a survey of DPDK an 1/3 of it is never used by any open > source project. Hate to see more dead code and special cases created. > > At least, some example code in examples would help. Something like a > simple in memory compressed storage server using a network API > (SMB?/SSH?/FTP?) [Fiona] There is no compressdev sample app yet. However I've double-checked with the SPDK team, they're currently integrating compressdev and intend to push a patch to SPDK - a storage open-source project - using this flag. Acked-by: Paul Luse
[dpdk-dev] Question / possible issue with vdev_scan() in secondary process
Hi,
I have a test case where vdev_scan() is being called in a secondary process as
shown below in a snippet from the function. My test application is compiled
with AddressSanitizer which was complaining about a memory leak of memory
allocated in rte_mp_request_sync(). I added the free() call shown below and
this seems to have addressed the problem. Also looking at other callers of
rte_mp_request_sync(), they seem to free the reply->msgs memory from the
calling code as well.
Can anyone confirm that this is an issue and that this is the correct fix?
Thanks!
Paul
if (rte_eal_process_type() == RTE_PROC_SECONDARY) {
struct rte_mp_msg mp_req, *mp_rep;
struct rte_mp_reply mp_reply;
struct timespec ts = {.tv_sec = 5, .tv_nsec = 0};
struct vdev_param *req = (struct vdev_param *)mp_req.param;
struct vdev_param *resp;
strlcpy(mp_req.name, VDEV_MP_KEY, sizeof(mp_req.name));
mp_req.len_param = sizeof(*req);
mp_req.num_fds = 0;
req->type = VDEV_SCAN_REQ;
if (rte_mp_request_sync(&mp_req, &mp_reply, &ts) == 0 &&
mp_reply.nb_received == 1) {
mp_rep = &mp_reply.msgs[0];
resp = (struct vdev_param *)mp_rep->param;
VDEV_LOG(INFO, "Received %d vdevs", resp->num);
free(mp_reply.msgs); // <- I ADDED THIS
} else
VDEV_LOG(ERR, "Failed to request vdev from primary");
/* Fall through to allow private vdevs in secondary process */
}
Re: [dpdk-dev] [PATCH 3/6] net/tap: check interface name in kvargs
Thanks Jim!!
-from my iPhone
> On Jan 11, 2019, at 11:37 AM, Wiles, Keith wrote:
>
>
>
>> On Jan 11, 2019, at 12:06 PM, Stephen Hemminger
>> wrote:
>>
>> If interface name is passed to remote or iface then check
>> the length and for invalid characters. This avoids problems where
>> name gets truncated or rejected by kernel.
>>
>> Signed-off-by: Stephen Hemminger
>> ---
>> drivers/net/tap/rte_eth_tap.c | 37 +++
>> 1 file changed, 33 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c
>> index d7f77d664502..6a388eed0dd4 100644
>> --- a/drivers/net/tap/rte_eth_tap.c
>> +++ b/drivers/net/tap/rte_eth_tap.c
>> @@ -37,6 +37,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include
>> #include
>> @@ -1884,6 +1885,23 @@ eth_dev_tap_create(struct rte_vdev_device *vdev, char
>> *tap_name,
>>return -EINVAL;
>> }
>>
>> +/* make sure name is a possible Linux network device name */
>> +static bool is_valid_iface(const char *name)
>
> I am sorry, but the function name must be on the next line as per the style.
> I know you do not like it, but that is what the style states.
>> +{
>> +if (*name == '\0')
>> +return false;
>> +
>> +if (strnlen(name, IFNAMSIZ) == IFNAMSIZ)
>> +return false;
>> +
>> +while (*name) {
>> +if (*name == '/' || *name == ':' || isspace(*name))
>> +return false;
>> +name++;
>> +}
>> +return true;
>> +}
>> +
>> static int
>> set_interface_name(const char *key __rte_unused,
>> const char *value,
>> @@ -1891,12 +1909,17 @@ set_interface_name(const char *key __rte_unused,
>> {
>>char *name = (char *)extra_args;
>>
>> -if (value)
>> +if (value) {
>> +if (!is_valid_iface(value)) {
>> +TAP_LOG(ERR, "TAP invalid remote interface name (%s)",
>> +value);
>> +return -1;
>> +}
>>strlcpy(name, value, RTE_ETH_NAME_MAX_LEN);
>> -else
>> +} else {
>>snprintf(name, RTE_ETH_NAME_MAX_LEN, "%s%d",
>> DEFAULT_TAP_NAME, tun_unit - 1);
>> -
>> +}
>
> This is also a one line else and the style states to remove the {}.
>>return 0;
>> }
>>
>> @@ -1907,8 +1930,14 @@ set_remote_iface(const char *key __rte_unused,
>> {
>>char *name = (char *)extra_args;
>>
>> -if (value)
>> +if (value) {
>> +if (!is_valid_iface(value)) {
>> +TAP_LOG(ERR, "TAP invalid remote interface name (%s)",
>> +value);
>> +return -1;
>> +}
>>strlcpy(name, value, RTE_ETH_NAME_MAX_LEN);
>> +}
>>
>>return 0;
>> }
>> --
>> 2.20.1
>>
>
> I hate having to be the style police, but until we use something to validate
> the DPDK coding style (as I posted the uncrustify config last month) we have
> to keep the style the same or change the DPDK coding standard.
>
> Regards,
> Keith
>
[dpdk-dev] Question on AESNI PMD
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
[dpdk-dev] Question on AESNI PMD
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
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 Cc: dev@dpdk.org; De Lara Guarch, Pablo ; Doherty, Declan 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
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 ; Thomas Monjalon Cc: dev@dpdk.org; Doherty, Declan 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 > Cc: dev@dpdk.org; De Lara Guarch, Pablo > ; Doherty, Declan > > 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 > Cc: dev@dpdk.org; De Lara Guarch, Pablo > ; Doherty, Declan > > 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
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 ; Thomas Monjalon Cc: dev@dpdk.org; Doherty, Declan ; Harris, James R ; Verkamp, Daniel 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 ; Thomas Monjalon Cc: dev@dpdk.org; Doherty, Declan 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 > Cc: dev@dpdk.org; De Lara Guarch, Pablo > ; Doherty, Declan > > 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 > Cc: dev@dpdk.org; De Lara Guarch, Pablo > ; Doherty, Declan > > 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
Any thoughts on this? -Original Message- From: Luse, Paul E Sent: Wednesday, March 14, 2018 5:43 PM To: De Lara Guarch, Pablo ; 'Thomas Monjalon' Cc: 'dev@dpdk.org' ; Doherty, Declan ; Harris, James R ; Verkamp, Daniel 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 ; Thomas Monjalon Cc: dev@dpdk.org; Doherty, Declan ; Harris, James R ; Verkamp, Daniel 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 ; Thomas Monjalon Cc: dev@dpdk.org; Doherty, Declan 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 > Cc: dev@dpdk.org; De Lara Guarch, Pablo > ; Doherty, Declan > > 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 > Cc: dev@dpdk.org; De Lara Guarch, Pablo > ; Doherty, Declan > > 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 about recent change to rte_mbuf struct - user data and udata64 feels (breaks SPDK)
Hi, Recently this patch https://github.com/DPDK/dpdk/commit/5284adad3e95025f9901869f581c8c04ea642d32 made the following change: * mbuf: Removed the unioned fields ``userdata`` and ``udata64`` from the structure ``rte_mbuf``. It is replaced with dynamic fields. Which breaks the SPDK project’s crypto and compression capabilities as we use userdata to store context for our operation so it can be retrieved upcon completion of the operation. It’s not clear to me that we are safe to use the fields that were added: uint64_t dynfield1[2]; /**< Reserved for dynamic fields. */ uint64_t dynfield1[3]; /**< Reserved for dynamic fields. */ based on the comments. Can someone please advise, why was this done and can we use these fields? Thanks, Paul
Re: [dpdk-dev] Question about recent change to rte_mbuf struct - user data and udata64 feels (breaks SPDK)
Great, thanks for the quick response!! -Paul From: Thomas Monjalon Date: Thursday, November 19, 2020 at 2:30 AM To: Luse, Paul E Cc: dev@dpdk.org , olivier.m...@6wind.com Subject: Re: [dpdk-dev] Question about recent change to rte_mbuf struct - user data and udata64 feels (breaks SPDK) Hi, 19/11/2020 01:17, Luse, Paul E: > Hi, > > Recently this patch > https://github.com/DPDK/dpdk/commit/5284adad3e95025f9901869f581c8c04ea642d32 > made the following change: > > * mbuf: Removed the unioned fields ``userdata`` and ``udata64`` > from the structure ``rte_mbuf``. It is replaced with dynamic fields. > > Which breaks the SPDK project’s crypto and compression capabilities as we use > userdata to store context for our operation so it can be retrieved upcon > completion of the operation. It’s not clear to me that we are safe to use > the fields that were added: > > uint64_t dynfield1[2]; /**< Reserved for dynamic fields. */ > uint64_t dynfield1[3]; /**< Reserved for dynamic fields. */ > > based on the comments. Can someone please advise, why was this done and can > we use these fields? We are doing some API changes in DPDK 20.11. The mbuf changes were explained one year ago: http://fast.dpdk.org/events/slides/DPDK-2019-09-Dynamic_mbuf.pdf The API for dynamic fields is available since DPDK 19.11: http://doc.dpdk.org/guides/prog_guide/mbuf_lib.html#dynamic-fields-and-flags If you want an example, look how it is used in example apps.
