From: Jesper Dangaard Brouer <brouer@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: netdev@vger.kernel.org, BjörnTöpel <bjorn.topel@intel.com>,
magnus.karlsson@intel.com, eugenia@mellanox.com,
"John Fastabend" <john.fastabend@gmail.com>,
"Eran Ben Elisha" <eranbe@mellanox.com>,
"Saeed Mahameed" <saeedm@mellanox.com>,
galp@mellanox.com, "Daniel Borkmann" <borkmann@iogearbox.net>,
"Alexei Starovoitov" <alexei.starovoitov@gmail.com>,
"Tariq Toukan" <tariqt@mellanox.com>,
brouer@redhat.com
Subject: Re: [bpf-next V2 PATCH 10/15] xdp: rhashtable with allocator ID to pointer mapping
Date: Tue, 20 Mar 2018 15:27:25 +0100 [thread overview]
Message-ID: <20180320152725.5ea01d34@redhat.com> (raw)
In-Reply-To: <6950eb76-8e3d-60f2-6de1-005a4e4fd3f6@redhat.com>
On Tue, 20 Mar 2018 10:26:50 +0800
Jason Wang <jasowang@redhat.com> wrote:
> On 2018年03月19日 17:48, Jesper Dangaard Brouer wrote:
> > On Fri, 16 Mar 2018 16:45:30 +0800
> > Jason Wang <jasowang@redhat.com> wrote:
> >
> >> On 2018年03月10日 00:07, Jesper Dangaard Brouer wrote:
> >>> On Fri, 9 Mar 2018 21:07:36 +0800
> >>> Jason Wang <jasowang@redhat.com> wrote:
> >>>
> >>>>>>> Use the IDA infrastructure for getting a cyclic increasing ID number,
> >>>>>>> that is used for keeping track of each registered allocator per
> >>>>>>> RX-queue xdp_rxq_info.
> >>>>>>>
> >>>>>>> Signed-off-by: Jesper Dangaard Brouer<brouer@redhat.com>
> >>>>>> A stupid question is, can we manage to unify this ID with NAPI id?
> >>>>> Sorry I don't understand the question?
> >>>> I mean can we associate page poll pointer to napi_struct, record NAPI id
> >>>> in xdp_mem_info and do lookup through NAPI id?
> >>> No. The driver can unreg/reg a new XDP memory model,
> >>
> >> Is there an actual use case for this?
> >
> > I believe this is the common use case. When attaching an XDP/bpf prog,
> > then the driver usually want to change the RX-ring memory model
> > (different performance trade off).
>
> Right, but a single driver should only have one XDP memory model.
No! -- a driver can have multiple XDP memory models, based on different
performance trade offs and hardware capabilities.
The mlx5 (100Gbit/s) driver/hardware is a good example, which need
different memory models. It already support multiple RX memory models,
depending on HW support. So, I predict that we hit at performance
limit around 42Mpps on PCIe (I can measure 36Mpps), this is due to
PCI-express translations/sec limit. The mlx5 HW supports a compressed
descriptor format which deliver packets in several pages (based on
offset and len), thus lowering the needed PCIe transactions. The
pitfall is that this comes tail room limitations, which can be okay if
e.g. the users use-case does not involve cpumap.
Plus, when a driver need to support AF_XDP zero-copy, that also count
as another XDP memory model...
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
next prev parent reply other threads:[~2018-03-20 14:27 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-08 13:07 [bpf-next V2 PATCH 00/15] XDP redirect memory return API Jesper Dangaard Brouer
2018-03-08 13:07 ` [bpf-next V2 PATCH 01/15] mlx5: basic XDP_REDIRECT forward support Jesper Dangaard Brouer
2018-03-08 13:07 ` [bpf-next V2 PATCH 02/15] xdp: introduce xdp_return_frame API and use in cpumap Jesper Dangaard Brouer
2018-03-09 7:24 ` Jason Wang
2018-03-09 9:35 ` Jesper Dangaard Brouer
2018-03-09 13:04 ` Jason Wang
2018-03-09 16:05 ` Jesper Dangaard Brouer
2018-03-16 8:43 ` Jason Wang
2018-03-08 13:07 ` [bpf-next V2 PATCH 03/15] ixgbe: use xdp_return_frame API Jesper Dangaard Brouer
2018-03-08 13:08 ` [bpf-next V2 PATCH 04/15] xdp: move struct xdp_buff from filter.h to xdp.h Jesper Dangaard Brouer
2018-03-08 13:08 ` [bpf-next V2 PATCH 05/15] xdp: introduce a new xdp_frame type Jesper Dangaard Brouer
2018-03-08 13:08 ` [bpf-next V2 PATCH 06/15] tun: convert to use generic xdp_frame and xdp_return_frame API Jesper Dangaard Brouer
2018-03-08 15:16 ` Jesper Dangaard Brouer
2018-03-09 7:16 ` Jason Wang
2018-03-09 8:46 ` Jesper Dangaard Brouer
2018-03-08 13:08 ` [bpf-next V2 PATCH 07/15] virtio_net: " Jesper Dangaard Brouer
2018-03-09 8:03 ` Jason Wang
2018-03-09 9:44 ` Jesper Dangaard Brouer
2018-03-09 13:11 ` Jason Wang
2018-03-08 13:08 ` [bpf-next V2 PATCH 08/15] bpf: cpumap convert to use generic xdp_frame Jesper Dangaard Brouer
2018-03-08 13:08 ` [bpf-next V2 PATCH 09/15] mlx5: register a memory model when XDP is enabled Jesper Dangaard Brouer
2018-03-08 13:08 ` [bpf-next V2 PATCH 10/15] xdp: rhashtable with allocator ID to pointer mapping Jesper Dangaard Brouer
2018-03-09 8:08 ` Jason Wang
2018-03-09 9:37 ` Jesper Dangaard Brouer
2018-03-09 13:07 ` Jason Wang
2018-03-09 16:07 ` Jesper Dangaard Brouer
2018-03-16 8:45 ` Jason Wang
2018-03-19 9:48 ` Jesper Dangaard Brouer
2018-03-20 2:26 ` Jason Wang
2018-03-20 14:27 ` Jesper Dangaard Brouer [this message]
2018-03-22 2:16 ` Jason Wang
2018-03-08 13:08 ` [bpf-next V2 PATCH 11/15] page_pool: refurbish version of page_pool code Jesper Dangaard Brouer
2018-03-08 13:08 ` [bpf-next V2 PATCH 12/15] xdp: allow page_pool as an allocator type in xdp_return_frame Jesper Dangaard Brouer
2018-03-08 13:08 ` [bpf-next V2 PATCH 13/15] mlx5: use page_pool for xdp_return_frame call Jesper Dangaard Brouer
2018-03-08 13:08 ` [bpf-next V2 PATCH 14/15] xdp: transition into using xdp_frame for return API Jesper Dangaard Brouer
2018-03-08 13:08 ` [bpf-next V2 PATCH 15/15] xdp: transition into using xdp_frame for ndo_xdp_xmit Jesper Dangaard Brouer
2018-03-08 15:03 ` [bpf-next V2 PATCH 00/15] XDP redirect memory return API Alexander Duyck
2018-03-08 15:30 ` Jesper Dangaard Brouer
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=20180320152725.5ea01d34@redhat.com \
--to=brouer@redhat.com \
--cc=alexei.starovoitov@gmail.com \
--cc=bjorn.topel@intel.com \
--cc=borkmann@iogearbox.net \
--cc=eranbe@mellanox.com \
--cc=eugenia@mellanox.com \
--cc=galp@mellanox.com \
--cc=jasowang@redhat.com \
--cc=john.fastabend@gmail.com \
--cc=magnus.karlsson@intel.com \
--cc=netdev@vger.kernel.org \
--cc=saeedm@mellanox.com \
--cc=tariqt@mellanox.com \
/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;
as well as URLs for NNTP newsgroup(s).