On 2018年03月20日 22:27, Jesper Dangaard Brouer wrote:

On Tue, 20 Mar 2018 10:26:50 +0800
Jason Wang [off-list ref] wrote:

quoted

On 2018年03月19日 17:48, Jesper Dangaard Brouer wrote:

quoted

On Fri, 16 Mar 2018 16:45:30 +0800
Jason Wang [off-list ref] wrote:
  

quoted

On 2018年03月10日 00:07, Jesper Dangaard Brouer wrote:

quoted

On Fri, 9 Mar 2018 21:07:36 +0800
Jason Wang [off-list ref] wrote:
     

quoted

quoted

quoted

quoted

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<redacted>

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 let me correct my question, not familiar with mlx5e driver but if I 
understand correctly, driver (mlx5) will not change memory model during 
runtime for each NAPI. So NAPI id still work in this case?

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...

Yes or TAP zero-copy XDP. But it looks to me that we don't even need to 
care about the recycling here since the pages belongs to userspace.

Thanks