All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
To: Jesper Dangaard Brouer <brouer@redhat.com>
Cc: David Miller <davem@davemloft.net>,
	grygorii.strashko@ti.com, hawk@kernel.org, ast@kernel.org,
	linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org,
	xdp-newbies@vger.kernel.org, ilias.apalodimas@linaro.org,
	netdev@vger.kernel.org, daniel@iogearbox.net,
	jakub.kicinski@netronome.com, john.fastabend@gmail.com
Subject: Re: [PATCH v3 net-next 0/7] net: ethernet: ti: cpsw: Add XDP support
Date: Thu, 6 Jun 2019 16:24:22 +0300	[thread overview]
Message-ID: <20190606132420.GA12429@khorivan> (raw)
In-Reply-To: <20190606100850.72a48a43@carbon>

On Thu, Jun 06, 2019 at 10:08:50AM +0200, Jesper Dangaard Brouer wrote:
>On Wed, 05 Jun 2019 12:14:50 -0700 (PDT)
>David Miller <davem@davemloft.net> wrote:
>
>> From: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
>> Date: Wed,  5 Jun 2019 16:20:02 +0300
>>
>> > This patchset adds XDP support for TI cpsw driver and base it on
>> > page_pool allocator. It was verified on af_xdp socket drop,
>> > af_xdp l2f, ebpf XDP_DROP, XDP_REDIRECT, XDP_PASS, XDP_TX.
>>
>> Jesper et al., please give this a good once over.
>
>The issue with merging this, is that I recently discovered two bug with
>page_pool API, when using DMA-mappings, which result in missing
>DMA-unmap's.  These bugs are not "exposed" yet, but will get exposed
>now with this drivers.
>
>The two bugs are:
>
>#1: in-flight packet-pages can still be on remote drivers TX queue,
>while XDP RX driver manage to unregister the page_pool (waiting 1 RCU
>period is not enough).
>
>#2: this patchset also introduce page_pool_unmap_page(), which is
>called before an XDP frame travel into networks stack (as no callback
>exist, yet).  But the CPUMAP redirect *also* needs to call this, else we
>"leak"/miss DMA-unmap.
>
>I do have a working prototype, that fixes these two bugs.  I guess, I'm
>under pressure to send this to the list soon...

In particular "cpsw" case no dma unmap issue and if no changes in page_pool
API then no changes to the driver required. page_pool_unmap_page() is
used here for consistency reasons with attention that it can be
inherited/reused by other SoCs for what it can be relevant.

One potential change as you mentioned is with dropping page_pool_destroy() that,
now, can look like:

@@ -571,7 +571,6 @@ static void cpsw_destroy_rx_pool(struct cpsw_priv *priv, int ch)
                return;
 
        xdp_rxq_info_unreg(&priv->xdp_rxq[ch]);
-       page_pool_destroy(priv->page_pool[ch]);
        priv->page_pool[ch] = NULL;
 }

>From what I know there is ongoing change for adding switchdev to cpsw that can
change a lot and can require more work to rebase / test this patchset, so I want
to believe it can be merged before this.

-- 
Regards,
Ivan Khoronzhuk

WARNING: multiple messages have this Message-ID (diff)
From: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
To: Jesper Dangaard Brouer <brouer@redhat.com>
Cc: David Miller <davem@davemloft.net>,
	grygorii.strashko@ti.com, hawk@kernel.org, ast@kernel.org,
	linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org,
	xdp-newbies@vger.kernel.org, ilias.apalodimas@linaro.org,
	netdev@vger.kernel.org, daniel@iogearbox.net,
	jakub.kicinski@netronome.com, john.fastabend@gmail.com
Subject: Re: [PATCH v3 net-next 0/7] net: ethernet: ti: cpsw: Add XDP support
Date: Thu, 6 Jun 2019 16:24:22 +0300	[thread overview]
Message-ID: <20190606132420.GA12429@khorivan> (raw)
In-Reply-To: <20190606100850.72a48a43@carbon>

On Thu, Jun 06, 2019 at 10:08:50AM +0200, Jesper Dangaard Brouer wrote:
>On Wed, 05 Jun 2019 12:14:50 -0700 (PDT)
>David Miller <davem@davemloft.net> wrote:
>
>> From: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
>> Date: Wed,  5 Jun 2019 16:20:02 +0300
>>
>> > This patchset adds XDP support for TI cpsw driver and base it on
>> > page_pool allocator. It was verified on af_xdp socket drop,
>> > af_xdp l2f, ebpf XDP_DROP, XDP_REDIRECT, XDP_PASS, XDP_TX.
>>
>> Jesper et al., please give this a good once over.
>
>The issue with merging this, is that I recently discovered two bug with
>page_pool API, when using DMA-mappings, which result in missing
>DMA-unmap's.  These bugs are not "exposed" yet, but will get exposed
>now with this drivers.
>
>The two bugs are:
>
>#1: in-flight packet-pages can still be on remote drivers TX queue,
>while XDP RX driver manage to unregister the page_pool (waiting 1 RCU
>period is not enough).
>
>#2: this patchset also introduce page_pool_unmap_page(), which is
>called before an XDP frame travel into networks stack (as no callback
>exist, yet).  But the CPUMAP redirect *also* needs to call this, else we
>"leak"/miss DMA-unmap.
>
>I do have a working prototype, that fixes these two bugs.  I guess, I'm
>under pressure to send this to the list soon...

In particular "cpsw" case no dma unmap issue and if no changes in page_pool
API then no changes to the driver required. page_pool_unmap_page() is
used here for consistency reasons with attention that it can be
inherited/reused by other SoCs for what it can be relevant.

One potential change as you mentioned is with dropping page_pool_destroy() that,
now, can look like:

@@ -571,7 +571,6 @@ static void cpsw_destroy_rx_pool(struct cpsw_priv *priv, int ch)
                return;
 
        xdp_rxq_info_unreg(&priv->xdp_rxq[ch]);
-       page_pool_destroy(priv->page_pool[ch]);
        priv->page_pool[ch] = NULL;
 }

From what I know there is ongoing change for adding switchdev to cpsw that can
change a lot and can require more work to rebase / test this patchset, so I want
to believe it can be merged before this.

-- 
Regards,
Ivan Khoronzhuk

  reply	other threads:[~2019-06-06 13:24 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-05 13:20 [PATCH v3 net-next 0/7] net: ethernet: ti: cpsw: Add XDP support Ivan Khoronzhuk
2019-06-05 13:20 ` [PATCH v3 net-next 1/7] net: page_pool: add helper function to retrieve dma addresses Ivan Khoronzhuk
2019-06-05 13:20 ` [PATCH v3 net-next 2/7] net: page_pool: add helper function to unmap " Ivan Khoronzhuk
2019-06-05 13:20 ` [PATCH v3 net-next 3/7] net: ethernet: ti: cpsw: use cpsw as drv data Ivan Khoronzhuk
2019-06-05 13:20 ` [PATCH v3 net-next 4/7] net: ethernet: ti: cpsw_ethtool: simplify slave loops Ivan Khoronzhuk
2019-06-05 13:20 ` [PATCH v3 net-next 5/7] net: ethernet: ti: davinci_cpdma: add dma mapped submit Ivan Khoronzhuk
2019-06-05 13:20 ` [PATCH v3 net-next 6/7] net: ethernet: ti: davinci_cpdma: return handler status Ivan Khoronzhuk
2019-06-05 13:20 ` [PATCH v3 net-next 7/7] net: ethernet: ti: cpsw: add XDP support Ivan Khoronzhuk
2019-06-05 19:14 ` [PATCH v3 net-next 0/7] net: ethernet: ti: cpsw: Add " David Miller
2019-06-06  8:08   ` Jesper Dangaard Brouer
2019-06-06 13:24     ` Ivan Khoronzhuk [this message]
2019-06-06 13:24       ` Ivan Khoronzhuk
2019-06-06 20:56     ` David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190606132420.GA12429@khorivan \
    --to=ivan.khoronzhuk@linaro.org \
    --cc=ast@kernel.org \
    --cc=brouer@redhat.com \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=grygorii.strashko@ti.com \
    --cc=hawk@kernel.org \
    --cc=ilias.apalodimas@linaro.org \
    --cc=jakub.kicinski@netronome.com \
    --cc=john.fastabend@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=xdp-newbies@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.