I do not fully understand the usecase here, but if you are ready to maintain your fork of VPP you can definitely add whatever fields in whatever cacheline - just do not change the cacheline size unless you know what you do. Another option you could consider is whether you can write your own nodes to select the ipsec SA based on your own logic as encrypt/decrypt nodes use the SA index from vnet_buffer (b[0])->ipsec.sad_index.
Best ben > -----Original Message----- > From: Vijay Kumar <vjkumar2...@gmail.com> > Sent: lundi 20 décembre 2021 18:17 > To: Benoit Ganne (bganne) <bga...@cisco.com> > Cc: vpp-dev <vpp-dev@lists.fd.io> > Subject: Re: [vpp-dev] Adding new fields to ipsec_sa_t giving STATIC > ASSERT > > Hi Benoit, > > Thanks for the clarification. > > I still need a new field in the ipsec_sa_t to differentiate b/w 2 child > SAs that are established between the same end points. My use-case is like: > I need to use one child SA to carry the signaling traffic while I want to > use the other child SA to carry the data-traffic. As fd.io <http://fd.io> > IKEv2 is a route-based IPSEC VPN, in the outbound direction, I don't have > any method to do flow matching (SPD matching) to select appropriate SA. > > I want to program the ipsec_tun_protect object (itp_out_sa) with my > signaling child SA that gets used in esp_encrypt_inline() while looking up > the ipsec_tun_protect obj by adj_index. On the other hand, I want to use > the 2nd child SA to encrypt the outgoing data-traffic which I lookup based > on a new bihash that I have created that gives me the sa_index based on my > lookup key (pdu_sess_id+qfi) > > If I add the new field after cacheline1 mark, there is no issue during > compilation but I know it is not a good idea. > > Is it possible to suggest something because I feel it is inevitable to > solve my use-case without introducing a new field which would identify if > the child SA is for signaling or data-traffic? > > Kindly give your valuable suggestion in this regard. > > > > > > > On Mon, Dec 20, 2021 at 7:25 PM Benoit Ganne (bganne) <bga...@cisco.com > <mailto:bga...@cisco.com> > wrote: > > > That's the whole point of the assert: to prevent growing the data > structure beyond 1 cacheline. If you do so, you'll access 2 cachelines > instead of 1 in the common case, making it slower. > Changing CLIB_CACHE_LINE_BYTES is a very bad idea as it will change > the layout of many internal data structures, wasting memory and hurting > prefetch. > > Best > ben > > > -----Original Message----- > > From: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> <vpp- > d...@lists.fd.io <mailto:vpp-dev@lists.fd.io> > On Behalf Of Vijay Kumar > > Sent: lundi 20 décembre 2021 11:52 > > To: vpp-dev <vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> > > > Subject: [vpp-dev] Adding new fields to ipsec_sa_t giving STATIC > ASSERT > > > > Hi experts, > > > > I am facing a compilation issue due to the STATIC assert defined > on > > cacheline1 field in the ipsec_sa_t. > > > > I tried to add 2 new fields above the (ALIGN_MARK macro mentioned) > for my > > product specific use-case but I am unable to add because of this > static > > ASSERT > > > > /* data accessed by dataplane code should be above this comment */ > > CLIB_CACHE_LINE_ALIGN_MARK (cacheline1); > > > > > > It looks like I have to increase the CLIB_CACHE_LINE_BYTES which > is (1 << > > 6) 64 bytes? > > > > Will it have any impact on perf if it is made 128 (1 << 7)? > > > > > > Regards. > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20658): https://lists.fd.io/g/vpp-dev/message/20658 Mute This Topic: https://lists.fd.io/mt/87853862/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
