> >>
> >> Packet context ptr will not work in the case in which the packet is
> >> directly received from the interface by the offload engine.
> >> Is the above case valid or all the packet comes only through the
> application?
> >
> > In this API draft the packets come only through the application,
> > but I think SA context is still quite useful in that case too.
> > I think from application point of view an SA context is always
> > needed, regardless of whether it is explicit in the API or buried
> > in the packet context by the application.
>
> Actually this got me thinking, when the hard limit expires then the is
> no need for implementation to process the packet it can simply return
> the same packet. So application has to take care of re-submitting the
> packet again. Not sure if this is documented already IMO this should
> be explicitly documented.
That's the intention. Depending on an error status either the original or a
transformed packet is returned as a result. There's now this text in result
structure document:
/** Pointer to an array of per packet operation results
*
* Operation outputs results for each outputted packet into this array.
* The array must have at least 'num_pkt' elements. The results include
* operation status and packet form information for each outputted
* packet.
*
* For example, some packets may not have been transformed due to
* an error, but the original packet is returned with appropriate
* packet result information instead.
*/
odp_ipsec_packet_result_t *res;
} odp_ipsec_op_result_t;
We just need more documentation on each error case e.g. what kind of packet is
returned, etc. This can be also done during the development of the
implementation and validation tests.
>
> >
> >> In-case the above scenario is valid, my suggestion is to have a
> >> context_ptr per SA so that all packets belonging to a single SA will
> >> have the same context_ptr (implementation will update the ctx_ptr
> >> field of the output packet with the "ctx_packet_ptr" given in the SA)
> >> so it will be easier for application to maintain context per SA and
> >> there will not be a need to create one queue per SA.
> >
> > There is a user defined SA context pointer in the SA in this API
> > draft and I think the intention was to provide it back to the
> > application as part of odp_ipsec_packet_result_t. But maybe there
> > is an error there as there does not seem to be any way to actually
> > get the context pointer after SA creation.
> >
> > Now the packet result struct has the SA handle, which alone is
> > not very useful to the application. I think the API draft
> > should either include the user defined SA context pointer in
> > odp_ipsec_packet_result_t (and maybe also remove the plain SA
> > handle), or provide a way to get the SA context through an
> > SA handle. I would prefer the former.
>
> I agree, SA handle in result is not very efficient, since you need
> another in-direction to get the "context_ptr" from SA handle.
> I was actually thinking since each packet already has a packet context
> associated maybe we can update the packet context as the context_ptr
> stored in the SA.
>
> Else there will be two "context" per packet one - packet context ptr
> and another being the context ptr associated with the SA.
> Not sure if both are needed.
The problem of updating packet context pointer is that it's documented as a
user defined pointer. Implementation should not change it, but prefetch it or
copy it from packet to packet.
A function to get the ctx pointer of a SA would fit best our other APIs. It
should be pretty fast operation. The most performance overhead / benefit comes
from the cache miss / avoidance of the miss when application access the data
behind the SA ctx pointer.
void *odp_ipsec_sa_context(odp_ipsec_sa_t sa)
{
return ((struct sa_t *)sa->ctx;
}
When application calls this the sa struct is already hot in cache and the
sa->ctx has already been prefetched.
-Petri
