From mboxrd@z Thu Jan  1 00:00:00 1970
From: =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= <bjorn.topel@gmail.com>
Subject: Re: [RFC PATCH v2 00/14] Introducing AF_XDP support
Date: Thu, 29 Mar 2018 08:16:23 +0200
Message-ID: <CAJ+HfNi+WX-0Q_zQLnvRhJGvWSDaFXzi2EBPVA6c6Znh=cRC=g@mail.gmail.com>
References: <20180327165919.17933-1-bjorn.topel@gmail.com> <047ba6b20383140529812e3f2579a8a2bfe1906b.camel@regit.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: "Karlsson, Magnus" <magnus.karlsson@intel.com>,
        "Duyck, Alexander H" <alexander.h.duyck@intel.com>,
        Alexander Duyck <alexander.duyck@gmail.com>,
        John Fastabend <john.fastabend@gmail.com>,
        Alexei Starovoitov <ast@fb.com>,
        Jesper Dangaard Brouer <brouer@redhat.com>,
        Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
        Daniel Borkmann <daniel@iogearbox.net>,
        Netdev <netdev@vger.kernel.org>,
        =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= <bjorn.topel@intel.com>,
        michael.lundkvist@ericsson.com,
        "Brandeburg, Jesse" <jesse.brandeburg@intel.com>,
        "Singhai, Anjali" <anjali.singhai@intel.com>,
        "Zhang, Qi Z" <qi.z.zhang@intel.com>, ravineet.singh@ericsson.com
To: Eric Leblond <eric@regit.org>
Return-path: <netdev-owner@vger.kernel.org>
Received: from mail-qt0-f170.google.com ([209.85.216.170]:46793 "EHLO
        mail-qt0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751150AbeC2GQY (ORCPT
        <rfc822;netdev@vger.kernel.org>); Thu, 29 Mar 2018 02:16:24 -0400
Received: by mail-qt0-f170.google.com with SMTP id h4so5146066qtn.13
        for <netdev@vger.kernel.org>; Wed, 28 Mar 2018 23:16:24 -0700 (PDT)
In-Reply-To: <047ba6b20383140529812e3f2579a8a2bfe1906b.camel@regit.org>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

2018-03-28 23:18 GMT+02:00 Eric Leblond <eric@regit.org>:
> Hello,
>
> On Tue, 2018-03-27 at 18:59 +0200, Bj=C3=B6rn T=C3=B6pel wrote:
>> From: Bj=C3=B6rn T=C3=B6pel <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 ?
>

Exactly! The XDP program executing for a certain Rx queue will
distribute the packets to the socket(s) in the xskmap.

>> 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.
>

Thanks for trying it out! All input is very much appreciated
(clunkiness of API, crashes...)!


Bj=C3=B6rn

> Best regards,
> --
> Eric Leblond