dpss shared memory: wait on freeListFree lock timed out

Document created by cdnadmin on Jan 25, 2014
Version 1Show Document
  • View in full screen mode
This document was generated from CDN thread

Created by: Viktor S. Wold Eide on 29-04-2013 06:21:36 AM
Hi,

In a callback handler we set *return_pak = FALSE to indicate to the
platform that the packet is to be dropped. However, after some time we
get the output included below from the dpss_mp_32-0.7.0.503 process.

Is this a known issue or are we missing something? The documentation
seems somewhat unclear. Is it necessary to perform some additional
steps to drop packets?

The debug output from the dpss process seems to indicate that the
queue size is not the problem.

Note also that terminating the client is not sufficient for the dpss
process to clean up its internal state. Hence, it is necessary to
terminate and then restart the dpss process.
<cut>

CFT Engine: CFT_ERRMSG_CLIENT_API, Mon Jan 05 05:06:51.832 CET :
CFT Engine: CFT_ERRMSG_CLIENT_API, Mon Jan 05 05:06:51.832 CET :
CFT Engine: CFT_ERRMSG_CLIENT_API, Mon Jan 05 05:06:51.832 CET : src/posix/onep_posix_shared_memory_queue.c:91: shared memory: enqueing packet
Mon Jan 05 05:06:51.833 CET : src/posix/onep_posix_shared_memory_queue.c:121: queue #[0] enqueue at ndx 98, queue size = 1
Mon Jan 05 05:06:52.835 CET : src/posix/onep_dpss_shared_memory_queue_private.c:318: shared memory: allocating packet
Mon Jan 05 05:06:52.838 CET : src/main/onep_dpss_engine.c:604: Received 204 bytes from platform
Mon Jan 05 05:06:52.839 CET : src/shared/onep_dpss_paktype.c:110: platform messaging: Decoded message from platform of type 1
Mon Jan 05 05:06:52.840 CET :
CFT Engine: CFT_ERRMSG_CLIENT_API, Mon Jan 05 05:06:52.840 CET :
CFT Engine: CFT_ERRMSG_CLIENT_API, Mon Jan 05 05:06:52.840 CET :
CFT Engine: CFT_ERRMSG_CLIENT_API, Mon Jan 05 05:06:52.841 CET : src/posix/onep_posix_shared_memory_queue.c:91: shared memory: enqueing packet
Mon Jan 05 05:06:52.841 CET : src/posix/onep_posix_shared_memory_queue.c:121: queue #[0] enqueue at ndx 99, queue size = 1
Mon Jan 05 05:06:53.843 CET : src/posix/onep_dpss_shared_memory_queue_private.c:318: shared memory: allocating packet
Mon Jan 05 05:06:53.845 CET : src/posix/onep_dpss_shared_memory_queue_private.c:320: shared memory: wait on freeListFree lock timed out
Mon Jan 05 05:06:53.846 CET : src/main/onep_dpss_engine.c:571: Could not alloc packet
Mon Jan 05 05:06:54.851 CET : src/posix/onep_dpss_shared_memory_queue_private.c:318: shared memory: allocating packet
Mon Jan 05 05:06:54.852 CET : src/posix/onep_dpss_shared_memory_queue_private.c:320: shared memory: wait on freeListFree lock timed out
Mon Jan 05 05:06:54.853 CET : src/main/onep_dpss_engine.c:571: Could not alloc packet
Mon Jan 05 05:06:55.029 CET : src/main/onep_dpss_engine.c:1088: Retrieved rpc handle for client with id 15
Mon Jan 05 05:06:55.030 CET :
Deleting fid:1 Mon Jan 05 05:06:55.030 CET : <10.0.229.11:34500,Mon Jan 05 05:06:55.031 CET : 10.0.225.255:34500,Mon Jan 05 05:06:55.031 CET : 17,0>0
Mon Jan 05 05:06:55.031 CET :
CFT Ager: aged out flow 1
Mon Jan 05 05:06:55.859 CET : src/posix/onep_dpss_shared_memory_queue_private.c:318: shared memory: allocating packet
Mon Jan 05 05:06:55.861 CET : src/posix/onep_dpss_shared_memory_queue_private.c:320: shared memory: wait on freeListFree lock timed out
Mon Jan 05 05:06:55.862 CET : src/main/onep_dpss_engine.c:571: Could not alloc packet
Mon Jan 05 05:06:56.867 CET : src/posix/onep_dpss_shared_memory_queue_private.c:318: shared memory: allocating packet
Mon Jan 05 05:06:56.869 CET : src/posix/onep_dpss_shared_memory_queue_private.c:320: shared memory: wait on freeListFree lock timed out

<cut>

Best regards
Viktor

Subject: Re: New Message from Viktor S. Wold Eide in onePK - Troubleshooting: dpss s
Replied by: Einar Nilsen-Nygaard on 29-04-2013 06:42:07 AM
Viktor,

The best way to drop a packet is just to call "onep_dpss_drop_packet()". By setting *return_pak to FALSE what you are actually indicating is that you wish to keep the packet reference, and since the packets are a shared (and limited) resource, if you keep on doing that you will run out. Invoking onep_dpss_drop_packet() both drops the packet (if it was diverted) and returns it for reuse.

Note that we've had feedback that the APIs in this area are a little confusing, so we will be trying to do better.

Cheers,

Einar

On 29 Apr 2013, at 12:21, "Cisco Developer Community Forums" <cdicuser@developer.cisco.com<mailto:cdicuser@developer.cisco.com>> wrote:

Viktor S. Wold Eide has created a new message in the forum "Troubleshooting": -------------------------------------------------------------- Hi,

In a callback handler we set *return_pak = FALSE to indicate to the
platform that the packet is to be dropped. However, after some time we
get the output included below from the dpss_mp_32-0.7.0.503 process.

Is this a known issue or are we missing something? The documentation
seems somewhat unclear. Is it necessary to perform some additional
steps to drop packets?

The debug output from the dpss process seems to indicate that the
queue size is not the problem.

Note also that terminating the client is not sufficient for the dpss
process to clean up its internal state. Hence, it is necessary to
terminate and then restart the dpss process.
<cut>

CFT Engine: CFT_ERRMSG_CLIENT_API, Mon Jan 05 05:06:51.832 CET :
CFT Engine: CFT_ERRMSG_CLIENT_API, Mon Jan 05 05:06:51.832 CET :
CFT Engine: CFT_ERRMSG_CLIENT_API, Mon Jan 05 05:06:51.832 CET : src/posix/onep_posix_shared_memory_queue.c:91: shared memory: enqueing packet
Mon Jan 05 05:06:51.833 CET : src/posix/onep_posix_shared_memory_queue.c:121: queue #[0] enqueue at ndx 98, queue size = 1
Mon Jan 05 05:06:52.835 CET : src/posix/onep_dpss_shared_memory_queue_private.c:318: shared memory: allocating packet
Mon Jan 05 05:06:52.838 CET : src/main/onep_dpss_engine.c:604: Received 204 bytes from platform
Mon Jan 05 05:06:52.839 CET : src/shared/onep_dpss_paktype.c:110: platform messaging: Decoded message from platform of type 1
Mon Jan 05 05:06:52.840 CET :
CFT Engine: CFT_ERRMSG_CLIENT_API, Mon Jan 05 05:06:52.840 CET :
CFT Engine: CFT_ERRMSG_CLIENT_API, Mon Jan 05 05:06:52.840 CET :
CFT Engine: CFT_ERRMSG_CLIENT_API, Mon Jan 05 05:06:52.841 CET : src/posix/onep_posix_shared_memory_queue.c:91: shared memory: enqueing packet
Mon Jan 05 05:06:52.841 CET : src/posix/onep_posix_shared_memory_queue.c:121: queue #[0] enqueue at ndx 99, queue size = 1
Mon Jan 05 05:06:53.843 CET : src/posix/onep_dpss_shared_memory_queue_private.c:318: shared memory: allocating packet
Mon Jan 05 05:06:53.845 CET : src/posix/onep_dpss_shared_memory_queue_private.c:320: shared memory: wait on freeListFree lock timed out
Mon Jan 05 05:06:53.846 CET : src/main/onep_dpss_engine.c:571: Could not alloc packet
Mon Jan 05 05:06:54.851 CET : src/posix/onep_dpss_shared_memory_queue_private.c:318: shared memory: allocating packet
Mon Jan 05 05:06:54.852 CET : src/posix/onep_dpss_shared_memory_queue_private.c:320: shared memory: wait on freeListFree lock timed out
Mon Jan 05 05:06:54.853 CET : src/main/onep_dpss_engine.c:571: Could not alloc packet
Mon Jan 05 05:06:55.029 CET : src/main/onep_dpss_engine.c:1088: Retrieved rpc handle for client with id 15
Mon Jan 05 05:06:55.030 CET :
Deleting fid:1 Mon Jan 05 05:06:55.030 CET : <10.0.229.11:34500,Mon Jan 05 05:06:55.031 CET : 10.0.225.255:34500,Mon Jan 05 05:06:55.031 CET : 17,0>0
Mon Jan 05 05:06:55.031 CET :
CFT Ager: aged out flow 1
Mon Jan 05 05:06:55.859 CET : src/posix/onep_dpss_shared_memory_queue_private.c:318: shared memory: allocating packet
Mon Jan 05 05:06:55.861 CET : src/posix/onep_dpss_shared_memory_queue_private.c:320: shared memory: wait on freeListFree lock timed out
Mon Jan 05 05:06:55.862 CET : src/main/onep_dpss_engine.c:571: Could not alloc packet
Mon Jan 05 05:06:56.867 CET : src/posix/onep_dpss_shared_memory_queue_private.c:318: shared memory: allocating packet
Mon Jan 05 05:06:56.869 CET : src/posix/onep_dpss_shared_memory_queue_private.c:320: shared memory: wait on freeListFree lock timed out

<cut>

Best regards
Viktor
--
To respond to this post, please click the following link: http://developer.cisco.com/web/onepk/community/-/message_boards/view_message/14752828 or simply reply to this email.

Subject: Re: New Message from Einar Nilsen-Nygaard in onePK - Troubleshooting: Re: N
Replied by: Viktor S. Wold Eide on 29-04-2013 07:57:07 AM
Hi Einar,

Yes, that's a little confusing, having both the function
onep_dpss_drop_packet() and *return_pak. Maybe a set of different
predefined return values would be less confusing. Anyhow, good to hear that
this will be made clearer.

Better cleanup in the dpss process to avoid manually restarting the process
is also welcomed.

Best regards
Viktor


2013/4/29 Cisco Developer Community Forums <cdicuser@developer.cisco.com>

> Einar Nilsen-Nygaard has created a new message in the forum
> "Troubleshooting":
> -------------------------------------------------------------- Viktor,
>
> The best way to drop a packet is just to call "onep_dpss_drop_packet()".
> By setting *return_pak to FALSE what you are actually indicating is that
> you wish to keep the packet reference, and since the packets are a shared
> (and limited) resource, if you keep on doing that you will run out.
> Invoking onep_dpss_drop_packet() both drops the packet (if it was diverted)
> and returns it for reuse.
>
> Note that we've had feedback that the APIs in this area are a little
> confusing, so we will be trying to do better.
>
> Cheers,
>
> Einar
>

Attachments

    Outcomes