[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160408134158.0f153ff9@redhat.com>
Date: Fri, 8 Apr 2016 13:41:58 +0200
From: Jesper Dangaard Brouer <brouer@...hat.com>
To: Brenden Blanco <bblanco@...mgrid.com>
Cc: davem@...emloft.net, netdev@...r.kernel.org, tom@...bertland.com,
alexei.starovoitov@...il.com, ogerlitz@...lanox.com,
daniel@...earbox.net, eric.dumazet@...il.com, ecree@...arflare.com,
john.fastabend@...il.com, tgraf@...g.ch, johannes@...solutions.net,
eranlinuxmellanox@...il.com, lorenzo@...gle.com, brouer@...hat.com
Subject: Re: [RFC PATCH v2 4/5] mlx4: add support for fast rx drop bpf
program
On Thu, 7 Apr 2016 21:48:49 -0700 Brenden Blanco <bblanco@...mgrid.com> wrote:
> +int mlx4_call_bpf(struct bpf_prog *prog, void *data, unsigned int length)
> +{
> + struct sk_buff *skb = this_cpu_ptr(&percpu_bpf_phys_dev_md);
> + int ret;
> +
> + build_bpf_phys_dev_md(skb, data, length);
> +
> + rcu_read_lock();
> + ret = BPF_PROG_RUN(prog, (void *)skb);
> + rcu_read_unlock();
> +
> + return ret;
> +}
[...]
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
> index 86bcfe5..287da02 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
> @@ -840,6 +843,23 @@ int mlx4_en_process_rx_cq(struct net_device *dev, struct mlx4_en_cq *cq, int bud
> l2_tunnel = (dev->hw_enc_features & NETIF_F_RXCSUM) &&
> (cqe->vlan_my_qpn & cpu_to_be32(MLX4_CQE_L2_TUNNEL));
>
> + /* A bpf program gets first chance to drop the packet. It may
> + * read bytes but not past the end of the frag.
> + */
> + if (prog) {
> + struct ethhdr *ethh;
> + dma_addr_t dma;
> +
> + dma = be64_to_cpu(rx_desc->data[0].addr);
> + dma_sync_single_for_cpu(priv->ddev, dma, sizeof(*ethh),
> + DMA_FROM_DEVICE);
> + ethh = page_address(frags[0].page) +
> + frags[0].page_offset;
> + if (mlx4_call_bpf(prog, ethh, frags[0].page_size) ==
> + BPF_PHYS_DEV_DROP)
> + goto next;
> + }
> +
Do the program need to know if the packet-page we handover is
considered 'read-only' at the call site? Or do we rely on my idea
requiring the registration to "know" this...
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
Powered by blists - more mailing lists