Hi Damjan, Dave,
Thanks for the quick reply.
It is really helpful. So the barrier ensures that the IPSec data structure
access is thread safe.
Have a few more question on the IPSec implementation.
1. The inbound SA lookup (in ipsec-input) is actually going through the
inbound policies for the given spd id linearly and matching a policy. The
SA is picked based on the matching policy.
This could have been an SAD hash table with key as (SPI, dst address,
proto (ESP or AH) ), so that the SA can be looked up from the hash on
receiving an ESP packet.
Is there a particular reason it is implemented using a linear policy
match?
2. There is also an IKEv2 responder implementation that adds/deletes IPSec
tunnel interfaces. How does this work? Is there any documentation that can
be referred to?
Thanks
Krishna
On Wed, Jun 27, 2018 at 6:23 PM, Dave Barach (dbarach) <dbar...@cisco.com>
wrote:
> +1.
>
>
>
> To amplify a bit: *all* binary API messages are processed with worker
> threads paused in a barrier sync, unless the API message has been
> explicitly marked thread-safe.
>
>
>
> Here is the relevant code in .../src/vlibapi/api_shared.c:
> vl_api_msg_handler_with_vm_node(...)
>
>
>
> if (!am->is_mp_safe[id])
>
> {
>
> vl_msg_api_barrier_trace_context (am->msg_names[id]);
>
> vl_msg_api_barrier_sync ();
>
> }
>
> (*handler) (the_msg, vm, node);
>
>
>
> if (!am->is_mp_safe[id])
>
> vl_msg_api_barrier_release ();
>
>
>
> Typical example of marking a message mp-safe:
>
>
>
> api_main_t *am=&api_main;
>
> ...
>
>
>
> am->is_mp_safe[VL_API_MEMCLNT_KEEPALIVE_REPLY] = 1;
>
>
>
> The debug CLI uses the same scheme. Unless otherwise marked mp-safe, debug
> CLI commands are executed with worker threads paused in a barrier sync.
>
>
>
> HTH... Dave
>
>
>
> -----Original Message-----
> From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Damjan Marion
> Sent: Wednesday, June 27, 2018 6:59 AM
> To: Vamsi Krishna <vamsi...@gmail.com>
> Cc: vpp-dev@lists.fd.io
> Subject: Re: [vpp-dev] Is VPP IPSec implementation thread safe?
>
>
>
> ipsec data structures are updated during barrier sync, so there is not
> packets in-flight...
>
>
>
>
>
> > On 27 Jun 2018, at 07:45, Vamsi Krishna <vamsi...@gmail.com> wrote:
>
> >
>
> > Hi ,
>
> >
>
> > I have looked at the ipsec code in VPP and trying to understand how it
> works in a multi threaded environment. Noticed that the datastructures for
> spd, sad and tunnel interface are pools and there are no locks to prevent
> race conditions.
>
> >
>
> > For instance the ipsec-input node passes SA index to the esp-encrypt
> node, and esp-encrypt node looks up the SA from sad pool. But during the
> time in which the packet is passed from one node to another the entry at SA
> index may be changed or deleted. Same seems to be true for dpdk-esp-encrypt
> and dpdk-esp-decrypt. How are these cases handled? Can the implementation
> be used in multi-threaded environment?
>
> >
>
> > Please help understand the IPSec implementation.
>
> >
>
> > Thanks
>
> > Krishna
>
> > -=-=-=-=-=-=-=-=-=-=-=-
>
> > Links: You receive all messages sent to this group.
>
> >
>
> > View/Reply Online (#9709): https://lists.fd.io/g/vpp-dev/message/9709
>
> > Mute This Topic: https://lists.fd.io/mt/22720913/675642
>
> > Group Owner: vpp-dev+ow...@lists.fd.io
>
> > Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [dmar...@me.com]
>
> > -=-=-=-=-=-=-=-=-=-=-=-
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9730): https://lists.fd.io/g/vpp-dev/message/9730
Mute This Topic: https://lists.fd.io/mt/22720913/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
