On Fri, 1 Apr 2016 18:21:57 -0700
Brenden Blanco <bbla...@plumgrid.com> wrote:
> @@ -840,6 +843,21 @@ 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. A non-zero
> + * return indicates packet should be dropped.
> + */
> + if (prog) {
> + struct ethhdr *ethh;
> +
> + ethh = (struct ethhdr *)(page_address(frags[0].page) +
> + frags[0].page_offset);
> + if (mlx4_call_bpf(prog, ethh, length)) {
> + priv->stats.rx_dropped++;
> + goto next;
> + }
> + }
> +
For future API, I can imagine more return codes being needed.
For forwarding I could imagine returning "STOLEN", which should not
increment rx_dropped.
One could also imagine supporting tcpdump/af_packet like facilities at
this packet-page level (e.g. af_packet queue packets into a RX ring
buffer, later processed/read async). It could return "SHARED", bumping
refcnt on page, and indicate page is now read-only. Thus, affecting
drivers processing flow.
--
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
