From: Christoph Hellwig <hch@lst.de>
To: "Björn Töpel" <bjorn.topel@intel.com>
Cc: "Christoph Hellwig" <hch@lst.de>,
"David S. Miller" <davem@davemloft.net>,
netdev@vger.kernel.org,
"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
bpf <bpf@vger.kernel.org>,
"Maxim Mikityanskiy" <maximmi@mellanox.com>,
"Karlsson, Magnus" <magnus.karlsson@intel.com>,
"Björn Töpel" <bjorn.topel@gmail.com>
Subject: Re: the XSK buffer pool needs be to reverted
Date: Fri, 26 Jun 2020 14:41:04 +0200 [thread overview]
Message-ID: <20200626124104.GA8835@lst.de> (raw)
In-Reply-To: <f1512c3e-79eb-ba75-6f38-ca09795973c1@intel.com>
On Fri, Jun 26, 2020 at 02:22:41PM +0200, Björn Töpel wrote:
> Thanks for clarifying that. Let's work on a solution that can reside in
> the dma mapping core.
>
>> The commit seems to have a long dove tail of commits depending on it
>> despite only being a month old, so maybe you can do the revert for now?
>>
>
> Reverting the whole series sounds a bit too much. Let's focus on the
> part that breaks the dma api abstraction. I'm assuming that you're
> referring to the
>
> static bool xp_check_cheap_dma(struct xsk_buff_pool *pool)
>
> function (and related functions called from that)?
Yes.
>
>> Note that this is somewhat urgent, as various of the APIs that the code
>> is abusing are slated to go away for Linux 5.9, so this addition comes
>> at a really bad time.
>>
>
> Understood. Wdyt about something in the lines of the diff below? It's
> build tested only, but removes all non-dma API usage ("poking
> internals"). Would that be a way forward, and then as a next step work
> on a solution that would give similar benefits, but something that would
> live in the dma mapping core?
Yes, that would solve the immediate issues.
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: "Björn Töpel" <bjorn.topel@intel.com>
Cc: Maxim Mikityanskiy <maximmi@mellanox.com>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
"David S. Miller" <davem@davemloft.net>,
iommu@lists.linux-foundation.org, bpf <bpf@vger.kernel.org>,
Christoph Hellwig <hch@lst.de>,
"Karlsson, Magnus" <magnus.karlsson@intel.com>
Subject: Re: the XSK buffer pool needs be to reverted
Date: Fri, 26 Jun 2020 14:41:04 +0200 [thread overview]
Message-ID: <20200626124104.GA8835@lst.de> (raw)
In-Reply-To: <f1512c3e-79eb-ba75-6f38-ca09795973c1@intel.com>
On Fri, Jun 26, 2020 at 02:22:41PM +0200, Björn Töpel wrote:
> Thanks for clarifying that. Let's work on a solution that can reside in
> the dma mapping core.
>
>> The commit seems to have a long dove tail of commits depending on it
>> despite only being a month old, so maybe you can do the revert for now?
>>
>
> Reverting the whole series sounds a bit too much. Let's focus on the
> part that breaks the dma api abstraction. I'm assuming that you're
> referring to the
>
> static bool xp_check_cheap_dma(struct xsk_buff_pool *pool)
>
> function (and related functions called from that)?
Yes.
>
>> Note that this is somewhat urgent, as various of the APIs that the code
>> is abusing are slated to go away for Linux 5.9, so this addition comes
>> at a really bad time.
>>
>
> Understood. Wdyt about something in the lines of the diff below? It's
> build tested only, but removes all non-dma API usage ("poking
> internals"). Would that be a way forward, and then as a next step work
> on a solution that would give similar benefits, but something that would
> live in the dma mapping core?
Yes, that would solve the immediate issues.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2020-06-26 12:41 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-26 7:47 the XSK buffer pool needs be to reverted Christoph Hellwig
2020-06-26 7:47 ` Christoph Hellwig
2020-06-26 12:22 ` Björn Töpel
2020-06-26 12:22 ` Björn Töpel
2020-06-26 12:41 ` Christoph Hellwig [this message]
2020-06-26 12:41 ` Christoph Hellwig
2020-06-26 12:45 ` Björn Töpel
2020-06-26 12:45 ` Björn Töpel
2020-06-26 20:54 ` Jonathan Lemon
2020-06-26 20:54 ` Jonathan Lemon
2020-06-27 7:02 ` Christoph Hellwig
2020-06-27 7:02 ` Christoph Hellwig
2020-06-29 13:15 ` Robin Murphy
2020-06-29 13:15 ` Robin Murphy
2020-06-30 19:08 ` Jonathan Lemon
2020-06-30 19:08 ` Jonathan Lemon
2020-07-01 9:46 ` Robin Murphy
2020-07-01 9:46 ` Robin Murphy
2020-07-06 19:59 ` Jonathan Lemon
2020-07-06 19:59 ` Jonathan Lemon
2020-07-07 17:35 ` Robin Murphy
2020-07-07 17:35 ` Robin Murphy
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=20200626124104.GA8835@lst.de \
--to=hch@lst.de \
--cc=bjorn.topel@gmail.com \
--cc=bjorn.topel@intel.com \
--cc=bpf@vger.kernel.org \
--cc=davem@davemloft.net \
--cc=iommu@lists.linux-foundation.org \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=magnus.karlsson@intel.com \
--cc=maximmi@mellanox.com \
--cc=netdev@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.