From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
Subject: Re: [PATCH v2 5/7] bpf: introduce basic RX/TX BPF filters
Date: Tue, 3 Apr 2018 04:14:41 +0530
Message-ID: <20180402224440.GB1501@jerin>
References: <1520613725-9176-1-git-send-email-konstantin.ananyev@intel.com>
 <1522431163-25621-6-git-send-email-konstantin.ananyev@intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: dev@dpdk.org
To: Konstantin Ananyev <konstantin.ananyev@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from NAM01-BN3-obe.outbound.protection.outlook.com
 (mail-bn3nam01on0045.outbound.protection.outlook.com [104.47.33.45])
 by dpdk.org (Postfix) with ESMTP id F2D9E1B3FD
 for <dev@dpdk.org>; Tue,  3 Apr 2018 00:45:01 +0200 (CEST)
Content-Disposition: inline
In-Reply-To: <1522431163-25621-6-git-send-email-konstantin.ananyev@intel.com>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

-----Original Message-----
> Date: Fri, 30 Mar 2018 18:32:41 +0100
> From: Konstantin Ananyev <konstantin.ananyev@intel.com>
> To: dev@dpdk.org
> CC: Konstantin Ananyev <konstantin.ananyev@intel.com>
> Subject: [dpdk-dev] [PATCH v2 5/7] bpf: introduce basic RX/TX BPF filters
> X-Mailer: git-send-email 1.7.0.7
> 
> Introduce API to install BPF based filters on ethdev RX/TX path.
> Current implementation is pure SW one, based on ethdev RX/TX
> callback mechanism.
> 
> Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> ---

Hi Konstantin,

> +/*
> + * Marks given callback as used by datapath.
> + */
> +static __rte_always_inline void
> +bpf_eth_cbi_inuse(struct bpf_eth_cbi *cbi)
> +{
> +	cbi->use++;
> +	/* make sure no store/load reordering could happen */
> +	rte_smp_mb();
> +}
> +
> +/*
> + * Marks given callback list as not used by datapath.
> + */
> +static __rte_always_inline void
> +bpf_eth_cbi_unuse(struct bpf_eth_cbi *cbi)
> +{
> +	/* make sure all previous loads are completed */
> +	rte_smp_rmb();

We earlier discussed this barrier. Will following scheme works out to
fix the bpf_eth_cbi_wait() without cbi->use scheme?

#ie. We need to exit from jitted or interpreted code irrespective of its
state. IMO, We can do that by an _arch_ specific function to fill jitted  memory with
"exit" opcode(value:0x95, exit, return r0),so that above code needs to be come out i n anycase,
on next instruction execution. I know, jitted memory is read-only in your
design, I think, we can change the permission to "write" to the fill
"exit" opcode(both jitted or interpreted case) for termination.


What you think?

> +	cbi->use++;
> +}
> +
> +/*
> + * Waits till datapath finished using given callback.
> + */
> +static void
> +bpf_eth_cbi_wait(const struct bpf_eth_cbi *cbi)
> +{
> +	uint32_t nuse, puse;
> +
> +	/* make sure all previous loads and stores are completed */
> +	rte_smp_mb();
> +
> +	puse = cbi->use;
> +
> +	/* in use, busy wait till current RX/TX iteration is finished */
> +	if ((puse & BPF_ETH_CBI_INUSE) != 0) {
> +		do {
> +			rte_pause();
> +			rte_compiler_barrier();
> +			nuse = cbi->use;
> +		} while (nuse == puse);
> +	}
> +}