From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 90B07C43331 for ; Mon, 30 Mar 2020 13:09:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5A88F20733 for ; Mon, 30 Mar 2020 13:09:54 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linux-powerpc-org.20150623.gappssmtp.com header.i=@linux-powerpc-org.20150623.gappssmtp.com header.b="CKZaiqs4" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730102AbgC3NJx (ORCPT ); Mon, 30 Mar 2020 09:09:53 -0400 Received: from mail-vs1-f68.google.com ([209.85.217.68]:44816 "EHLO mail-vs1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730070AbgC3NJx (ORCPT ); Mon, 30 Mar 2020 09:09:53 -0400 Received: by mail-vs1-f68.google.com with SMTP id e138so10884984vsc.11 for ; Mon, 30 Mar 2020 06:09:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-powerpc-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=W3kxTCjH2pPR1QQDH6RmWndnNmrbv4XaGPcFHpITCgo=; b=CKZaiqs4rZGDro59rNLrbLKfgimz7/R//63RNzuNR9oUcWUBdyDG8DR4vRy4fzspxP 1CQsPmEy8oitLUXwXKXVVA/FW6cr4J2K1gC1+yc8mL3BVeA3yIWewMxEv7jx/P8eJSHy 2x8yTxfYAfdu9/3ku+qzGmXqgAniBdz1sTCT1h4ywL7IDml5GGh5VrgrVCLrZ/pN9v5X 8rXnj3/Lusy3MrDo4gh3a9J4ZL4qZh9U4OaqaYHIL4Vea9bpnl6AQCj8DPdq4286WEP4 9xQbtPvQszBfZXlzerfKvvcTIqdDc6AH08VuR0s6ZLjkPcNQ7nLNBDGx2X9LpttZF2v0 +UXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=W3kxTCjH2pPR1QQDH6RmWndnNmrbv4XaGPcFHpITCgo=; b=XrLxKO1WIQcxAj13Oa8cKn4xLFMYA/471y6i1gHcyH2UUIcQACX5lcV32qPBWC0gZF obc2DDC9NOnLohrzzO6KrmqyeXDY4PEOI6LTC+GE91XckKoWzhZH5A4aC41o91GDzjtk g5o73f7Jsc2PzLazBRuhdKuHNMSmpCeFKARpTMiRPkdDaSYO9jKo43/n2Q/dxCrcj1yd 7e4IFyBgwsY2e4w+sgByeY5eu8onrijd+YLoVegi5v0wW7ZYapsfxZaBrbuT1m7RdUtH o/ue0/cpHLgwkX0ftY3BTwnh/ZzhWYci+iplhOw4NtUNWrL0SOb8q/XslPT3vQIzgocb IbiA== X-Gm-Message-State: AGi0Pubpl9WMgrcOTGNnRGrzD3vGV8J7YeRLFsHFIT7eeF5D+cEnxZbh zBSITWDi2boYk8PSnnSzdY4w3q++nMoq7+mihP8SKg== X-Google-Smtp-Source: APiQypJ+hMA+KXvE/MftB1AQhy2fhNaRzWwV0H5qpPGhMX/yNJIPB1/k+rLCdo0Os16oYcN317v5USwa6WGraFUVAJo= X-Received: by 2002:a67:e24c:: with SMTP id w12mr8966097vse.153.1585573790329; Mon, 30 Mar 2020 06:09:50 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab0:6507:0:0:0:0:0 with HTTP; Mon, 30 Mar 2020 06:09:49 -0700 (PDT) X-Originating-IP: [5.35.40.234] In-Reply-To: References: <1584364176-23346-1-git-send-email-kda@linux-powerpc.org> <250783b3-4949-d00a-70e2-dbef1791a6c4@suse.com> <9eb74bee-8434-62aa-8158-bae130353670@suse.com> From: Denis Kirjanov Date: Mon, 30 Mar 2020 16:09:49 +0300 Message-ID: Subject: Re: [PATCH net-next v4] xen networking: add basic XDP support for xen-netfront To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Cc: netdev@vger.kernel.org, ilias.apalodimas@linaro.org, wei.liu@kernel.org, paul@xen.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 3/30/20, J=C3=BCrgen Gro=C3=9F wrote: > On 30.03.20 14:16, Denis Kirjanov wrote: >> On 3/23/20, J=C3=BCrgen Gro=C3=9F wrote: >>> On 23.03.20 11:49, Denis Kirjanov wrote: >>>> On 3/23/20, J=C3=BCrgen Gro=C3=9F wrote: >>>>> On 23.03.20 11:15, Denis Kirjanov wrote: >>>>>> On 3/18/20, J=C3=BCrgen Gro=C3=9F wrote: >>>>>>> On 18.03.20 13:50, Denis Kirjanov wrote: >>>>>>>> On 3/18/20, J=C3=BCrgen Gro=C3=9F wrote: >>>>>>>>> On 16.03.20 14:09, Denis Kirjanov wrote: >>>>>>>>>> The patch adds a basic XDP processing to xen-netfront driver. >>>>>>>>>> >>>>>>>>>> We ran an XDP program for an RX response received from netback >>>>>>>>>> driver. Also we request xen-netback to adjust data offset for >>>>>>>>>> bpf_xdp_adjust_head() header space for custom headers. >>>>>>>>> >>>>>>>>> This is in no way a "verbose patch descriprion". >>>>>>>>> >>>>>>>>> I'm missing: >>>>>>>>> >>>>>>>>> - Why are you doing this. "Add XDP support" is not enough, for >>>>>>>>> such >>>>>>>>> a change I'd like to see some performance numbers to get a= n >>>>>>>>> idea >>>>>>>>> of the improvement to expect, or which additional >>>>>>>>> functionality >>>>>>>>> for the user is available. >>>>>>>> Ok, I'll try to measure some numbers. >>>>>>>> >>>>>>>>> >>>>>>>>> - A short description for me as a Xen maintainer with only basic >>>>>>>>> networking know-how, what XDP programs are about (a link t= o >>>>>>>>> some >>>>>>>>> more detailed doc is enough, of course) and how the >>>>>>>>> interface >>>>>>>>> is working (especially for switching between XDP mode and >>>>>>>>> normal >>>>>>>>> SKB processing). >>>>>>>> >>>>>>>> You can search for the "A practical introduction to XDP" tutorial. >>>>>>>> Actually there is a lot of information available regarding XDP, yo= u >>>>>>>> can easily find it. >>>>>>>> >>>>>>>>> >>>>>>>>> - A proper description of the netfront/netback communication when >>>>>>>>> enabling or disabling XDP mode (who is doing what, is >>>>>>>>> silencing >>>>>>>>> of the virtual adapter required, ...). >>>>>>>> Currently we need only a header offset from netback driver so that >>>>>>>> we >>>>>>>> can >>>>>>>> put >>>>>>>> custom encapsulation header if required and that's done using xen >>>>>>>> bus >>>>>>>> state switching, >>>>>>>> so that: >>>>>>>> - netback tells that it can adjust the header offset >>>>>>>> - netfront part reads it >>>>>>> >>>>>>> Yes, but how is this synchronized with currently running network >>>>>>> load? >>>>>>> Assume you are starting without XDP being active and then you are >>>>>>> activating it. How is the synchronization done from which request o= n >>>>>>> the XDP headroom is available? >>>>>> >>>>>> Hi Jurgen, >>>>>> >>>>>> basically XDP is activated when you've assigned an xdp program to th= e >>>>>> networking device. >>>>>> Assigning an xdp program means that we have to adjust a pointer whic= h >>>>>> is RCU protected. >>>>> >>>>> This doesn't answer my question. >>>>> >>>>> You have basically two communication channels: the state of the >>>>> frontend >>>>> and backend for activation/deactivation of XDP, and the ring pages >>>>> with >>>>> the rx and tx requests and responses. How is the synchronization >>>>> between >>>>> those two channels done? So how does the other side know which of the >>>>> packets in flight will then have XDP on or off? >>>> >>>> Right, >>>> that's done in xen-netback using xenbus state: >>>> - in xennet_xdp_set() we call xenbus_switch_state to tell xen-netback >>>> to >>>> adjust offset for an RX response. >>>> -xen-netback reads the value from xenstore and adjusts the offset for >>>> xen-netback >>>> in xenvif_rx_data_slot() using vif->xdp_enabled flag. >>> >>> And before that all in-flight requests in the ring pages are being >>> processed and no new requests are guaranteed to be enqueued? >> >> Actually I don't see the need to sync these requests since that all we >> have to do is to copy >> data with specified offset: >> with xdp->enabled=3D1: copy with the offset XDP_PACKET_HEADROOM >> with xdd->enabled=3D0: copy without the offset > > Isn't that racy? > > In xennet_xdp_set() you set queue->xdp_prog and then you change the > state to Reconfiguring. From the time queue->xdp_prog is set you'll > do the Xdp processing in xennet_get_responses(), even if the response > you are working on doesn't have the headroom you need, as the backend > didn't create it with headroom (it needs some time until it has seen > the new state and could react on it by sending _new_ responses with > headroom). Ah, I see. You mean that we have to wait until XenbusStateReconfigured is set in xen-netfront and only after that it's safe to process packets. > > Or am I missing something about Xdp programs? > > > Juergen >