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: Wed, 11 Apr 2018 14:17:53 +0200
Message-ID: <CAJ+HfNiJ+tS6cG4_cCj1syQC8m8OZWM44-NX-hbdRYWQj=98TA@mail.gmail.com>
References: <20180327165919.17933-1-bjorn.topel@gmail.com> <CALDO+SbsotUZ2oyuBGHDsdfr+=ffCUDQnFXxbgN3iggrW6xakw@mail.gmail.com>
 <CAJ+HfNgu+RE6G3=4dnyfaEZGxcw-NB1dAZKNgrZm0TFKooVdKQ@mail.gmail.com> <CALDO+SYvxrnqKy=7P2c_agWDJEn2spwNQr0ynE2-JTfWPAaEEg@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: "Karlsson, Magnus" <magnus.karlsson@intel.com>,
        Alexander Duyck <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>,
        Linux Kernel Network Developers <netdev@vger.kernel.org>,
        =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= <bjorn.topel@intel.com>,
        michael.lundkvist@ericsson.com,
        "Brandeburg, Jesse" <jesse.brandeburg@intel.com>,
        Anjali Singhai Jain <anjali.singhai@intel.com>,
        "Zhang, Qi Z" <qi.z.zhang@intel.com>, ravineet.singh@ericsson.com
To: William Tu <u9012063@gmail.com>
Return-path: <netdev-owner@vger.kernel.org>
Received: from mail-qt0-f173.google.com ([209.85.216.173]:43093 "EHLO
        mail-qt0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751898AbeDKMRy (ORCPT
        <rfc822;netdev@vger.kernel.org>); Wed, 11 Apr 2018 08:17:54 -0400
Received: by mail-qt0-f173.google.com with SMTP id s48so1600097qtb.10
        for <netdev@vger.kernel.org>; Wed, 11 Apr 2018 05:17:54 -0700 (PDT)
In-Reply-To: <CALDO+SYvxrnqKy=7P2c_agWDJEn2spwNQr0ynE2-JTfWPAaEEg@mail.gmail.com>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

2018-04-10 16:14 GMT+02:00 William Tu <u9012063@gmail.com>:
> On Mon, Apr 9, 2018 at 11:47 PM, Bj=C3=B6rn T=C3=B6pel <bjorn.topel@gmail=
.com> wrote:

[...]

>>>
>>
>> So you've setup two identical UMEMs? Then you can just forward the
>> incoming Rx descriptor to the other netdev's Tx queue. Note, that you
>> only need to copy the descriptor, not the actual frame data.
>>
>
> Thanks!
> I will give it a try, I guess you're saying I can do below:
>
> int sfd1; // for device1
> int sfd2; // for device2
> ...
> // create 2 umem
> umem1 =3D calloc(1, sizeof(*umem));
> umem2 =3D calloc(1, sizeof(*umem));
>
> // allocate 1 shared buffer, 1 xdp_umem_reg
> posix_memalign(&bufs, ...)
> mr.addr =3D (__u64)bufs; // shared for umem1,2
> ...
>
> // umem reg the same mr
> setsockopt(sfd1, SOL_XDP, XDP_UMEM_REG, &mr, sizeof(mr))
> setsockopt(sfd2, SOL_XDP, XDP_UMEM_REG, &mr, sizeof(mr))
>
> // setup fill, completion, mmap for sfd1 and sfd2
> ...
>
> Since both device can put frame data in 'bufs', I only need to copy
> the descs between 2 umem1 and umem2. Am I understand correct?
>

Yup, spot on! umem1 and umem2 have the same layout/index "address
space", so you can just forward the descriptors and never touch the
data.

In the current RFC you are required to create both an Rx and Tx queue
to bind the socket, which is just weird for your "Rx on one device, Tx
to another" scenario. I'll fix that in the next RFC.


Bj=C3=B6rn

> Regards,
> William