public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
To: Jesper Dangaard Brouer <brouer@redhat.com>
Cc: grygorii.strashko@ti.com, hawk@kernel.org, davem@davemloft.net,
	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 v2 net-next 7/7] net: ethernet: ti: cpsw: add XDP support
Date: Sat, 1 Jun 2019 02:27:28 +0300	[thread overview]
Message-ID: <20190531232727.GB15675@khorivan> (raw)
In-Reply-To: <20190601003736.65cb6a61@carbon>

On Sat, Jun 01, 2019 at 12:37:36AM +0200, Jesper Dangaard Brouer wrote:
>On Fri, 31 May 2019 20:03:33 +0300
>Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> wrote:
>
>> Probably it's not good example for others how it should be used, not
>> a big problem to move it to separate pools.., even don't remember why
>> I decided to use shared pool, there was some more reasons... need
>> search in history.
>
>Using a shared pool is makes it a lot harder to solve the issue I'm
>currently working on.  That is handling/waiting for in-flight frames to
>complete, before removing the mem ID from the (r)hashtable lookup.  I
>have working code, that basically remove page_pool_destroy() from
>public API, and instead lets xdp_rxq_info_unreg() call it when
>in-flight count reach zero (and delay fully removing the mem ID).

Frankly, not see reason why it can block smth, it can be considered
like not shared pool. But Ok, anyway it can look more logical and can be
reused by another SoC. I will add it per channel not a problem,
at least for now no blockers. Adding pool per channel will create more
page_pool_destroy() calls, per each pool, that I can be dropped once
you decided to remove it form the API.

This API is called along with xdp_rxq_info_unreg(), and seems like not
a problem to just remove page_pool_destroy(), except one case that
worries me... cpsw has one interesting feature, share same h/w with 2
network devices like dual mac, basically it's 3 port switch, but used
as 2 separate interfaces. So that, both of them share same queues/channels/rings.
XDP rxq requires network device to be set in rxq info, wich is used in the
code as a pointer and is shared between xdp buffers, so can't be changed in
flight. That's why each network interface has it's own instances of rxq, but
page pools per each network device is common, so when I call
xdp_rxq_info_unreg() per net device it doesn't mean I want to delete
page pool....But seems I can avoid it calling xdp_rxq_info_unreg()
for both when delete page pools...

>
>-- 
>Best regards,
>  Jesper Dangaard Brouer
>  MSc.CS, Principal Kernel Engineer at Red Hat
>  LinkedIn: http://www.linkedin.com/in/brouer

-- 
Regards,
Ivan Khoronzhuk

      reply	other threads:[~2019-05-31 23:27 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-30 18:20 [PATCH v2 net-next 0/7] net: ethernet: ti: cpsw: Add XDP support Ivan Khoronzhuk
2019-05-30 18:20 ` [PATCH v2 net-next 1/7] net: page_pool: add helper function to retrieve dma addresses Ivan Khoronzhuk
2019-05-30 18:20 ` [PATCH v2 net-next 2/7] net: page_pool: add helper function to unmap " Ivan Khoronzhuk
2019-05-30 18:20 ` [PATCH v2 net-next 3/7] net: ethernet: ti: cpsw: use cpsw as drv data Ivan Khoronzhuk
2019-06-01 10:49   ` grygorii
2019-05-30 18:20 ` [PATCH v2 net-next 4/7] net: ethernet: ti: cpsw_ethtool: simplify slave loops Ivan Khoronzhuk
2019-06-01 10:55   ` grygorii
2019-05-30 18:20 ` [PATCH v2 net-next 5/7] net: ethernet: ti: davinci_cpdma: add dma mapped submit Ivan Khoronzhuk
2019-05-30 18:20 ` [PATCH v2 net-next 6/7] net: ethernet: ti: davinci_cpdma: return handler status Ivan Khoronzhuk
2019-05-30 18:20 ` [PATCH v2 net-next 7/7] net: ethernet: ti: cpsw: add XDP support Ivan Khoronzhuk
2019-05-31 15:46   ` Jesper Dangaard Brouer
2019-05-31 16:25     ` Ivan Khoronzhuk
2019-05-31 16:32       ` Jesper Dangaard Brouer
2019-05-31 17:03         ` Ivan Khoronzhuk
2019-05-31 22:08           ` Saeed Mahameed
2019-05-31 23:00             ` Ivan Khoronzhuk
2019-05-31 22:37           ` Jesper Dangaard Brouer
2019-05-31 23:27             ` Ivan Khoronzhuk [this message]

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=20190531232727.GB15675@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox