From mboxrd@z Thu Jan  1 00:00:00 1970
From: Eric Leblond <eric@regit.org>
Subject: Re: [RFC PATCH v2 00/14] Introducing AF_XDP support
Date: Wed, 28 Mar 2018 23:18:19 +0200
Message-ID: <047ba6b20383140529812e3f2579a8a2bfe1906b.camel@regit.org>
References: <20180327165919.17933-1-bjorn.topel@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Cc: =?ISO-8859-1?Q?Bj=F6rn_T=F6pel?= <bjorn.topel@intel.com>,
        michael.lundkvist@ericsson.com, jesse.brandeburg@intel.com,
        anjali.singhai@intel.com, qi.z.zhang@intel.com,
        ravineet.singh@ericsson.com
To: =?ISO-8859-1?Q?Bj=F6rn_T=F6pel?= <bjorn.topel@gmail.com>,
        magnus.karlsson@intel.com, alexander.h.duyck@intel.com,
        alexander.duyck@gmail.com, john.fastabend@gmail.com, ast@fb.com,
        brouer@redhat.com, willemdebruijn.kernel@gmail.com,
        daniel@iogearbox.net, netdev@vger.kernel.org
Return-path: <netdev-owner@vger.kernel.org>
Received: from home.regit.org ([37.187.126.138]:33172 "EHLO home.regit.org"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1753011AbeC1VzL (ORCPT <rfc822;netdev@vger.kernel.org>);
        Wed, 28 Mar 2018 17:55:11 -0400
In-Reply-To: <20180327165919.17933-1-bjorn.topel@gmail.com>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

Hello,

On Tue, 2018-03-27 at 18:59 +0200, Björn Töpel wrote:
> From: Björn Töpel <bjorn.topel@intel.com>
> 
> 
optimized for high performance packet processing and, in upcoming
> patch sets, zero-copy semantics. In this v2 version, we have removed
> all zero-copy related code in order to make it smaller, simpler and
> hopefully more review friendly. This RFC only supports copy-mode for
> the generic XDP path (XDP_SKB) for both RX and TX and copy-mode for
> RX
> 

...
> 
> How is then packets distributed between these two XSK? We have
> introduced a new BPF map called XSKMAP (or BPF_MAP_TYPE_XSKMAP in
> full). The user-space application can place an XSK at an arbitrary
> place in this map. The XDP program can then redirect a packet to a
> specific index in this map and at this point XDP validates that the
> XSK in that map was indeed bound to that device and queue number. If
> not, the packet is dropped. If the map is empty at that index, the
> packet is also dropped. This also means that it is currently
> mandatory
> to have an XDP program loaded (and one XSK in the XSKMAP) to be able
> to get any traffic to user space through the XSK.

If I get it correctly, this feature will have to be used to bound
multiple sockets to a single queue and the eBPF filter will be
responsible of the load balancing. Am I correct ?

> AF_XDP can operate in two different modes: XDP_SKB and XDP_DRV. If
> the
> driver does not have support for XDP, or XDP_SKB is explicitly chosen
...

Thanks a lot for this work, I'm gonna try to implement this in
Suricata.

Best regards,