From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk0-f46.google.com (mail-vk0-f46.google.com [209.85.213.46]) by dpdk.org (Postfix) with ESMTP id 0D2BD37AC for ; Thu, 30 Mar 2017 22:17:38 +0200 (CEST) Received: by mail-vk0-f46.google.com with SMTP id r69so68543396vke.2 for ; Thu, 30 Mar 2017 13:17:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/lzARD3S+xgsDTZxSwcUAkegblDhePs45SmD2RsmSJc=; b=Z69m/YeI9UdQ9aeTImaEQHMz2pfIUgVOu42WgqTX0sRcrc+y1hOc1k27lVg4R648fP 4XJs2OH0bUGPgH2pWAUoaRw+/k6R9L+QpBqw8YSSuKu+CSLhsVEqRJiaI5sYAk1fSUVf Wyp2fPEorRpuMAyLAm+U+Zgk7Rwcy81qoj/MIWMcWWvE1AITekb3wqn60PbcTTjq9veK KU/ZGJsoN81kIbG/tLjAMxTh/mfrNIkyABl8RtGB673ukhD5fDL/UMjXRBBG4d6mnblo 3sfucZVAoo88V9Zo3vVWr8sQi0NOhuThsiXgk/ikZdzi7bXcecB7lLL3b+HI8Z0t+sgR Hb9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/lzARD3S+xgsDTZxSwcUAkegblDhePs45SmD2RsmSJc=; b=h/20webicSWBOos3lUk0u7frqkJK0f0pQERY+7kPwLA1eVzY6470fyCjAyOdajk/i1 ruy0bFlRjlgBHxqyaVnnvjKpgtMDP8wiIZ7PFdfdVinIjcp6cbQPdDU5CEL1w5VN3a9U Flav0mxfJ/heOkwkuJI6PGMjMqstZWKuR6nSiEAGnM7Y4FI1LelgGP1T/I604jCLTK9u LXxETkdcjOxDXqNty1yxCZ/ASmxiSxiEZXc4vtdIdA15llzp9+7YbfFuFZDr0pSTy9Eo co7RskXpwAry8V9Kh0hUAI5NgXa16hfJ7tNdWf260CXuKqGA29mWRtZOXvP+nPPqifVm 8+7Q== X-Gm-Message-State: AFeK/H1yck/DH7dA3sxE4jKCYq6YvF42amHfTbBrfjp5Smhius38JYeNuQMRZmsPisdDJ9I6aLA2osWECOHfxA== X-Received: by 10.31.160.210 with SMTP id j201mr819043vke.92.1490905057833; Thu, 30 Mar 2017 13:17:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.34.135 with HTTP; Thu, 30 Mar 2017 13:17:37 -0700 (PDT) In-Reply-To: <2601191342CEEE43887BDE71AB9772583FAE0668@IRSMSX109.ger.corp.intel.com> References: <2601191342CEEE43887BDE71AB9772583FADFE79@IRSMSX109.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772583FAE0654@IRSMSX109.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772583FAE0668@IRSMSX109.ger.corp.intel.com> From: Victor Detoni Date: Thu, 30 Mar 2017 17:17:37 -0300 Message-ID: To: "Ananyev, Konstantin" Cc: "dev@dpdk.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] Segm fault to the update acl context X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 20:17:39 -0000 Hi, I have tried to use rcu and rte_lock libs to synchronize but I put the ctx_reload before rte_acl_classify function and it is working fine. My code is working like this and I'm not having latency during reload process. while() { ... if (acl_ctx_reload) do_acl_reload(); if (acl_search.num_ipv4) { rte_acl_classify( acl_config.acx_ipv4[socketid], acl_search.data_ipv4, acl_search.res_ipv4, acl_search.num_ipv4, DEFAULT_MAX_CATEGORIES); send_packets(acl_search.m_ipv4, acl_search.res_ipv4, acl_search.num_ipv4); } } Thank you for your support. On Mon, Mar 27, 2017 at 8:34 PM, Ananyev, Konstantin < konstantin.ananyev@intel.com> wrote: > > > > > > Hi Konstantin, > > > > Thank you for your questions. Please find below a sample of my code: > > > > After the program has started, I send sighup signals to update the acl > context, like this: > > > > if (signup == SIGHUP) > > use_acl_ctx_swap = 1; > > ... > > During the SIGHUP processes I create a new/swap acl ctx and data > structures using the app_acl_init, add_rules and setup_acl > > functions > > Ok, so you do that inside your signal handler, correct? > Do you synchronize this context updates with your data-processing threads > somehow? > Konstantin > > > ... > > > > main_loop() > > ... > > if (use_acl_ctx_swap) { > > if (acl_search.num_ipv4) { > > rte_acl_classify( > > acl_config.swap_acx_ipv4[socketid], //use swap acl ctx > > acl_search.data_ipv4, > > acl_search.res_ipv4, > > acl_search.num_ipv4, > > DEFAULT_MAX_CATEGORIES); > > > > send_packets(acl_search.m_ipv4, > > acl_search.res_ipv4, > > acl_search.num_ipv4); > > > > } else { > > if (acl_search.num_ipv4) { > > rte_acl_classify( > > acl_config.acx_ipv4[socketid], > > acl_search.data_ipv4, > > acl_search.res_ipv4, > > acl_search.num_ipv4, > > DEFAULT_MAX_CATEGORIES); > > > > send_packets(acl_search.m_ipv4, > > acl_search.res_ipv4, > > acl_search.num_ipv4); > > } > > } > > > > When I update the acl ctx, rarely the program doesn't crash, mainly when > I just increase de rules. Is there a another way to add > > new/remove rules in the acl ctx instead of sighup or control variables? > > > > thanks > > Victor > > > > On Mon, Mar 27, 2017 at 6:23 AM, Ananyev, Konstantin < > konstantin.ananyev@intel.com> wrote: > > Hi Victor, > > > > > hello, > > > > > > I'm running l3fwd-acl example as a daemon and trying to update acl > context > > > with as a "swap" acl context, but the program stops with a segment > fault > > > statement. Even using variables to direct which acl context the main > loop > > > has to use, the program breaks. > > > > > > I have noticed that even when I update only the swap acl context, the > acl > > > structures are updated and the segment fault also happens. > > > > > > please, someone knows why this segment fault? > > > > As I remembers, l3fwd-acl doesn't support updating ACL ctx on the fly. > > Could you explain a bit more what are you trying to do, or even better > > provide some code example to reproduce the issue? > > > > Konstantin > >