On Mon, Apr 3, 2017 at 2:48 PM, Dmitry Eremin-Solenikov <[email protected]> wrote: > Hello, > > I was hunting last issues in my IPsec patchset. And suddently I was hit > by the fact that I do not fully understand semantics around > odp_ipsec_result() function. So here comes several questions: > > 1) Is is correct, that I have to free the event manually even after the > successful return from the function?
Every event received must be disposed of one way or another. When a worker receives an event of type odp_packet_t it must either free that packet or else send it on to some other processing stage. When an application receives an event of type odp_timeout_t it must also dispose of it either by rearming it or freeing it. An ODP_IPSEC_RESULT event is slightly different in that it is an opaque type that carries within it an odp_ipsec_result_t that may be retrieved from it via odp_ipsec_result(). As described in the doc for that function: * Copies IPSEC operation results from an event. The event must be of * type ODP_EVENT_IPSEC_RESULT. It must be freed before the application passes * any resulting packet handles to other ODP calls. The "It" here is perhaps a bit ambiguous, but refers to the odp_event_t. The caller supplies the odp_ipsec_result_t as an input to this routine and that is copied from the source event into that parameter (it's defined as an out parameter). Presumably this is just an area on the caller's stack so it requires no explicit freeing. So yes, you always have to free an event given to you by the scheduler. The odp_event_free() API does that in a universal manner for any type event. > > 2) What is the expected behaviour of the function if it is called with > result.num_pkt being too small? Should it output packets at this case? > Is it fine to output only some of the fragments from the single input > packet? (not that I support fragmentation at this moment, but still) > If it is called again (with larger num_pkt), should it re-output the > same packets, or should it continue from where it stopped? This is described in the API doc: * @return Number of packets in the event. If this is larger than * 'result.num_pkt', all packets did not fit into result struct and * application must call the function again with a larger result struct. So if the rc > result.num_pkt then the returned area will contain the results for packets 0..result.num_pkt-1 and the caller should make the call again with a larger result struct if it wishes to get the results from result.num_pkt..rc-1. I do not believe the intent is that this is stateful, meaning that ODP would remember how many were returned and continue returning from that point since otherwise there would be no need to call with a larger struct (the same struct could be used to iterate over all returned results). This is a good question, however, and is something we may wish to discuss further. I suspect it's easier for implementations to implement this function in a stateless manner, which is why this is phrased that way. > > The last question being the most important one, I think. > > -- > With best wishes > Dmitry
