On Mon, Apr 3, 2017 at 3:23 PM, Dmitry Eremin-Solenikov <dmitry.ereminsoleni...@linaro.org> wrote: > On 03.04.2017 23:13, Bill Fischofer wrote: >> On Mon, Apr 3, 2017 at 2:48 PM, Dmitry Eremin-Solenikov >> <dmitry.ereminsoleni...@linaro.org> 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. > > Yep. > >> >>> >>> 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. > > In fact, it would be much simpler (at least for SW implementation) to > implement it in stateful manner. It would be much simpler for apps to > read data from the event. I think we might want to discuss it on > Wednesday and maybe change this behaviour.
Agreed. In the meantime it would be good to get input on this question from HW implementations. > > -- > With best wishes > Dmitry
