Re: [PATCH vhost 3/6] virtio_net: replace private by pp struct inside page

On 17/04/2024 10.20, Xuan Zhuo wrote: On Wed, 17 Apr 2024 12:08:10 +0800, Jason Wang wrote: On Wed, Apr 17, 2024 at 9:38 AM Xuan Zhuo wrote: On Tue, 16 Apr 2024 11:24:53 +0800, Jason Wang wrote: On Mon, Apr 15, 2024 at 5:04 PM Xuan Zhuo wrote: On Mon, 15 Apr 2024 16:56:45 +0800, Jaso

Re: [PATCH v3 bpf-next] cpumap: bulk skb using netif_receive_skb_list

" xdp_pass=%u xdp_drop=%u xdp_redirect=%u", > __entry->cpu, __entry->map_id, > __print_symbolic(__entry->act, __XDP_ACT_SYM_TAB), > - __entry->processed, __entry->drops, > - __entry->sched, > + __entry->processed, __entry->sched, > __entry->xdp_pass, __entry->xdp_drop, __entry->xdp_redirect) > ); -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer

Re: [PATCH net-next v3 2/5] mm: add a signature in struct page

On Wed, 14 Apr 2021 13:09:47 -0700 Shakeel Butt wrote: > On Wed, Apr 14, 2021 at 12:42 PM Jesper Dangaard Brouer > wrote: > > > [...] > > > > > > > > Can this page_pool be used for TCP RX zerocopy? If yes then PageType > > > > can not be use

Re: [PATCH v8 bpf-next 00/14] mvneta: introduce XDP multi-buffer support

the mvneta card? How much are we > willing to pay for this feature when it is not being used or can we in > some way selectively turn it on only when needed? Well, as Daniel says performance wise we require close to /zero/ additional overhead, especially as you state this happens

Re: [PATCH 1/2] mm: Fix struct page layout on 32-bit systems

a > potential problem where (on a big endian platform), the bit used to denote > PageTail could inadvertently get set, and a racing get_user_pages_fast() > could dereference a bogus compound_head(). > > Fixes: c25fff7171be ("mm: add dma_addr_t to struct page") > Signed-

Re: [PATCH 1/1] mm: Fix struct page layout on 32-bit systems

On Fri, 16 Apr 2021 16:27:55 +0100 Matthew Wilcox wrote: > On Thu, Apr 15, 2021 at 08:08:32PM +0200, Jesper Dangaard Brouer wrote: > > See below patch. Where I swap32 the dma address to satisfy > > page->compound having bit zero cleared. (It is the simplest fix I coul

Re: [PATCH net-next] veth: check for NAPI instead of xdp_prog before xmit of XDP frame

land-Jørgensen > --- > drivers/net/veth.c | 7 +++ > 1 file changed, 3 insertions(+), 4 deletions(-) Acked-by: Jesper Dangaard Brouer Very happy to see this strange requirement of loading an xdp_prog on the veth peer (inside the netns) being lifted. Multiple people/users have hit th

Re: [PATCHv7 bpf-next 1/4] bpf: run devmap xdp_prog on flush instead of bulk enqueue

On Thu, 15 Apr 2021 17:39:13 -0700 Martin KaFai Lau wrote: > On Thu, Apr 15, 2021 at 10:29:40PM +0200, Toke Høiland-Jørgensen wrote: > > Jesper Dangaard Brouer writes: > > > > > On Thu, 15 Apr 2021 10:35:51 -0700 > > > Martin KaFai Lau wrote: > > &

Re: [PATCHv7 bpf-next 1/4] bpf: run devmap xdp_prog on flush instead of bulk enqueue

from the dev. It is from a devmap's elem. > > > > > Yeah, drivers call xdp_do_flush() before exiting their NAPI poll loop, > > which also runs under one big rcu_read_lock(). So the storage in the > > bulk queue is quite temporary, it's just used for bu

Re: [PATCH 1/1] mm: Fix struct page layout on 32-bit systems

On Wed, 14 Apr 2021 21:56:39 + David Laight wrote: > From: Matthew Wilcox > > Sent: 14 April 2021 22:36 > > > > On Wed, Apr 14, 2021 at 09:13:22PM +0200, Jesper Dangaard Brouer wrote: > > > (If others want to reproduce). First I could not reproduce on ARM3

Re: [PATCH v2 bpf-next] cpumap: bulk skb using netif_receive_skb_list

misleading (as in: drops actually happening, but 0 are shown from the > tracepoint). > Given they are not considered stable API, I would just remove those to make > it clear > to users that they cannot rely on this counter anymore anyway. After Lorenzo's change, the 'drops' still count if kmem_cache_alloc_bulk cannot alloc SKBs. I guess that will not occur very often. But how can people/users debug such a case? Maybe the MM-layer can tell us? -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer

Re: [PATCH net] igb: Fix XDP with PTP enabled

On Thu, 15 Apr 2021 14:16:36 +0200 Kurt Kanzenbach wrote: > On Thu Apr 15 2021, Jesper Dangaard Brouer wrote: > > On Thu, 15 Apr 2021 11:21:45 +0200 > > Kurt Kanzenbach wrote: > > > >> When using native XDP with the igb driver, the XDP frame data doesn't

Re: [PATCH net] igb: Fix XDP with PTP enabled

--- > drivers/net/ethernet/intel/igb/igb_ptp.c | 21 --- > 3 files changed, 33 insertions(+), 37 deletions(-) -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer

Re: [PATCH net v3] i40e: fix the panic when running bpf in xdpdrv mode

("i40e: main driver core") > > Co-developed-by: Shujin Li > > Signed-off-by: Shujin Li > > Signed-off-by: Jason Xing > > Reviewed-by: Jesse Brandeburg > > @Jakub/@DaveM - feel free to apply this directly. Acked-by: Jesper

Re: [PATCH net-next v3 2/5] mm: add a signature in struct page

remember vaguely that this code path for (TCP RX zerocopy) uses page->private for tricks. And our patch [3/5] use page->private for storing xdp_mem_info. IMHO when the SKB travel into this TCP RX zerocopy code path, we should call page_pool_release_page() to release its DMA-mapping. > > [1] > > https://lore.kernel.org/linux-mm/20210316013003.25271-1-arjunroy.k...@gmail.com/ > > -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer

Re: [PATCH 1/1] mm: Fix struct page layout on 32-bit systems

ARCH=arm was needed to cause the issue by enabling CONFIG_ARCH_DMA_ADDR_T_64BIT. Details below signature. -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer From file: arch/arm/Kconfig config XEN bool &quo

Re: [PATCH 1/1] mm: Fix struct page layout on 32-bit systems

.kernel.org/netdev/YHHuE7g73mZNrMV4@enceladus/ [2] https://patchwork.kernel.org/project/netdevbpf/patch/20210409223801.104657-3-mcr...@linux.microsoft.com/ [3] https://lore.kernel.org/linux-mm/20210410024313.gx2531...@casper.infradead.org/ -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer

Re: [PATCH v2 bpf-next] cpumap: bulk skb using netif_receive_skb_list

b-list: ~3.15Mpps > > Signed-off-by: Lorenzo Bianconi Acked-by: Jesper Dangaard Brouer -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer

Re: [PATCH RFC net] igb: Fix XDP with PTP enabled

return 0; > > - igb_ptp_systim_to_hwtstamp(adapter, skb_hwtstamps(skb), > -le64_to_cpu(regval[1])); > + igb_ptp_systim_to_hwtstamp(adapter, &ts, le64_to_cpu(regval[1])); > > /* adjust timestamp for the RX latency based on link speed */ > if (adapter->hw.mac.type == e1000_i210) { > @@ -907,10 +905,8 @@ int igb_ptp_rx_pktstamp(struct igb_q_vector *q_vector, > void *va, > break; > } > } > - skb_hwtstamps(skb)->hwtstamp = > - ktime_sub_ns(skb_hwtstamps(skb)->hwtstamp, adjust); > > - return 0; > + return ktime_sub_ns(ts.hwtstamp, adjust); > } > > /** -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer

Re: [PATCH net-next v3 2/5] mm: add a signature in struct page

[2] for explaining your intent. I still worry about page->index, see [2]. [2] https://lore.kernel.org/netdev/2021044307.5087f958@carbon/ -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer

Re: [PATCH 1/1] mm: Fix struct page layout on 32-bit systems

ould you explain your intent here? I worry about @index. As I mentioned in other thread[1] netstack use page_is_pfmemalloc() (code copy-pasted below signature) which imply that the member @index have to be kept intact. In above, I'm unsure @index is untouched. [1] https://lore.kernel.org/lkml/2021041008

Re: Bogus struct page layout on 32-bit

} __attribute__((__packed__)) > __attribute__((__aligned__(4))); > > This presumably affects any 32-bit architecture with a 64-bit phys_addr_t > / dma_addr_t. Advice, please? I'm not sure that the 32-bit behavior is with 64-bit (dma) addrs. I don't have any 32-bit boards with 64-bit DMA. Cc. Ivan, wasn't your board (572x ?) 32-bit with driver 'cpsw' this case (where Ivan added XDP+page_pool) ? -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer

Re: [PATCH net-next v2 3/5] page_pool: Allow drivers to hint on SKB recycling

On Fri, 9 Apr 2021 22:01:51 +0300 Ilias Apalodimas wrote: > On Fri, Apr 09, 2021 at 11:56:48AM -0700, Jakub Kicinski wrote: > > On Fri, 2 Apr 2021 20:17:31 +0200 Matteo Croce wrote: > > > Co-developed-by: Jesper Dangaard Brouer > > > Co-developed-by: Matteo Croce

Re: [PATCH bpf-next] cpumap: bulk skb using netif_receive_skb_list

ded the original code, what do you think about it? I'm actually fine with not counting the drops in the tracepoint. As you say it is already accounted elsewere in MIB counters for the network stack. Which is actually better, as having this drop counter in tracepoint have confused people before (when using xdp_redirect_cpu). If they instead looked at the MIB counters, it should be easier to understand why the drop happens. -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer

Re: [PATCH net v2 1/1] xdp: fix xdp_return_frame() kernel BUG throw for page_pool memory model

PU: 0 PID: 3884 Comm: modprobe Tainted: G U E > 5.12.0-rc2+ #45 > > Changes in v2: > - This patch fixes the issue by making xdp_return_frame_no_direct() is >only called if napi_direct = true, as recommended for better by >Jesper Dangaard Brouer. Thanks! >

Re: [PATCH net 1/1] xdp: fix xdp_return_frame() kernel BUG throw for page_pool memory model

Hi Ong, Patch is in "Changes Requested". Thus, please send a V2 patch with suggested code changes below. --Jesper On Mon, 29 Mar 2021 18:25:08 +0200 Toke Høiland-Jørgensen wrote: > Jesper Dangaard Brouer writes: > > > On Mon, 29 Mar 2021 16:00:39 +0800 >

Re: [PATCH net-next v2 0/6] stmmac: Add XDP support

) I'm interested in playing with the hardwares Split Header (SPH) feature. As this was one of the use-cases for XDP multi-frame work. -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer

Re: [PATCH net 1/1] xdp: fix xdp_return_frame() kernel BUG throw for page_pool memory model

disabling napi_direct of > xdp_return_frame") > Signed-off-by: Ong Boon Leong > --- This looks correct to me. Acked-by: Jesper Dangaard Brouer > net/core/xdp.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/net/core/xdp.c b/net/core/xdp.

[PATCH mel-git 3/3] net: page_pool: convert to use alloc_pages_bulk_array variant

Using the API variant alloc_pages_bulk_array from page_pool was done in a separate patch to ease benchmarking the variants separately. Maintainers can squash patch if preferred. Signed-off-by: Jesper Dangaard Brouer --- include/net/page_pool.h |2 +- net/core/page_pool.c| 22

[PATCH mel-git 1/3] net: page_pool: refactor dma_map into own function page_pool_dma_map

In preparation for next patch, move the dma mapping into its own function, as this will make it easier to follow the changes. V2: make page_pool_dma_map return boolean (Ilias) Signed-off-by: Jesper Dangaard Brouer Signed-off-by: Mel Gorman Reviewed-by: Ilias Apalodimas --- net/core

[PATCH mel-git 2/3] net: page_pool: use alloc_pages_bulk in refill code path

/xdp-project/blob/master/areas/mem/page_pool06_alloc_pages_bulk.org Signed-off-by: Jesper Dangaard Brouer Signed-off-by: Mel Gorman --- net/core/page_pool.c | 72 -- 1 file changed, 46 insertions(+), 26 deletions(-) diff --git a/net/core

[PATCH mel-git 0/3] page_pool using alloc_pages_bulk API

9.3.1 20200408 (Red Hat 9.3.1-2) Intent is for Mel to pickup these patches. --- Jesper Dangaard Brouer (3): net: page_pool: refactor dma_map into own function page_pool_dma_map net: page_pool: use alloc_pages_bulk in refill code path net: page_pool: convert to use alloc_pages_bulk_

Re: [PATCH 0/3 v5] Introduce a bulk order-0 page allocator

On Tue, 23 Mar 2021 16:08:14 +0100 Jesper Dangaard Brouer wrote: > On Tue, 23 Mar 2021 10:44:21 + > Mel Gorman wrote: > > > On Mon, Mar 22, 2021 at 09:18:42AM +, Mel Gorman wrote: > > > This series is based on top of Matthew Wilcox's series "Ratio

Re: [PATCH net-next 0/6] page_pool: recycle buffers

ged, 138 insertions(+), 26 deletions(-) > > > > Just for the reference, I've performed some tests on 1G SoC NIC with > > this patchset on, here's direct link: [0] > > > > Thanks for the testing! > Any chance you can get a perf measurement on this? I guess you mean perf-report (--stdio) output, right? > Is DMA syncing taking a substantial amount of your cpu usage? (+1 this is an important question) > > > > [0] https://lore.kernel.org/netdev/20210323153550.130385-1-aloba...@pm.me > > -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer

Re: [PATCH 2/3] mm/page_alloc: Add a bulk page allocator

this cause the compiler to uninline the static function. My tests show you should inline __rmqueue_pcplist(). See patch I'm using below signature, which also have some benchmark notes. (Please squash it into your patch and drop these notes). -- Best regards, Jesper Dangaard Brouer

Re: [PATCH 0/3 v5] Introduce a bulk order-0 page allocator

> to check. I will rebase and check again. The current performance tests that I'm running, I observe that the compiler layout the code in unfortunate ways, which cause I-cache performance issues. I wonder if you could integrate below patch with your patchset? (just squash it) -- Best regards

Re: [PATCH net-next 6/6] mvneta: recycle buffers

e(frag), &xdp->rxq->mem); > } > > return skb; This cause skb_mark_for_recycle() to set 'skb->pp_recycle=1' multiple times, for the same SKB. (copy-pasted function below signature to help reviewers). This makes me question if we need an API for setti

Re: [PATCH 0/3 v5] Introduce a bulk order-0 page allocator

is cache-line is hot as LRU-list update just wrote into this cache-line. As the bulk size goes up, as Matthew pointed out, this cache-line might be pushed into L2-cache, and then need to be accessed again when prep_new_page() is called. Another observation is that moving prep_new_page() into

Re: [PATCH net-next] page_pool: let the compiler optimize and inline core functions

uct page *page_pool_refill_alloc_cache(struct page_pool *pool) > { > struct ptr_ring *r = &pool->ring; > @@ -181,7 +180,6 @@ static void page_pool_dma_sync_for_device(struct > page_pool *pool, > } > > /* slow path */ > -noinline > static struct page *__page_pool_a

Re: [PATCH 0/3 v5] Introduce a bulk order-0 page allocator

can be related to the stats counters got added/moved inside the loop, in this patchset. Previous results from: https://lore.kernel.org/netdev/20210319181031.44dd3113@carbon/ On Fri, 19 Mar 2021 18:10:31 +0100 Jesper Dangaard Brouer wrote: > BASELINE > single_page alloc+p

Re: [PATCH 2/5] mm/page_alloc: Add a bulk page allocator

nabled if using a list */ > + if (page_list) { > + list_for_each_entry(page, page_list, lru) { > + prep_new_page(page, 0, gfp, 0); > + } > + } > > return allocated; > > @@ -5056,7 +5086,10 @@ int __alloc_pages_bulk(

Re: [PATCH 0/7 v4] Introduce a bulk order-0 page allocator with two in-tree users

On Wed, 17 Mar 2021 16:52:32 + Alexander Lobakin wrote: > From: Jesper Dangaard Brouer > Date: Wed, 17 Mar 2021 17:38:44 +0100 > > > On Wed, 17 Mar 2021 16:31:07 + > > Alexander Lobakin wrote: > > > > > From: Mel Gorman > > > Date: F

Re: [PATCH 0/7 v4] Introduce a bulk order-0 page allocator with two in-tree users

t; > want to send the sunrpc and page_pool pre-requisites (patches 4 and 6) > > directly to the subsystem maintainers. While sunrpc is low-risk, I'm > > vaguely aware that there are other prototype series on netdev that affect > > page_pool. The conflict should be obvious in linux-next. -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer

[PATCH mel-git] net: page_pool: use alloc_pages_bulk in refill code path

(3,810,013 pps -> 4,308,208 pps). [1] https://github.com/xdp-project/xdp-project/blob/master/areas/mem/page_pool06_alloc_pages_bulk.org Signed-off-by: Jesper Dangaard Brouer Signed-off-by: Mel Gorman --- net/core/page_pool.c | 73 -- 1 file chan

[PATCH mel-git] Followup: Update [PATCH 7/7] in Mel's series

from 18% before, but I don't think the rewrite of the specific patch have anything to do with this. Notes on tests: https://github.com/xdp-project/xdp-project/blob/master/areas/mem/page_pool06_alloc_pages_bulk.org#test-on-mel-git-tree --- Jesper Dangaard Brouer (1): net: p

Re: [PATCH 2/5] mm/page_alloc: Add a bulk page allocator

an walking the linked list. Even-though my page_pool use-case doesn't have a sparse array to populate (like NFS/SUNRPC) then I can still use this API that Chuck is suggesting. Thus, I'm fine with this :-) (p.s. working on implementing Alexander Duyck's suggestions, but I don'

Re: [PATCH 7/7] net: page_pool: use alloc_pages_bulk in refill code path

x27;t you need to potentially unmap the page before you call > > put_page on it? > > Oops, I completely missed that. Alexander is right here. Well, the put_page() case can never happen as the pool->alloc.cache[] is known to be empty when this function is called. I do agree that the code looks cumbersome and should free the DMA mapping, if it could happen. -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer

Re: [PATCH v3 net-next 0/2] pktgen: scripts improvements

> > v3: change us to ns in docs > v2: Review comments from Jesper > > CC: Jesper Dangaard Brouer Did a quick review and everything looks okay. The patches are already applied, but you will still get my ACK, even-though it will not make it to the commit log. Acked-by: Jesper

Re: [PATCH 7/7] net: page_pool: use alloc_pages_bulk in refill code path

ght but I'm punting this to Jesper to fix. He's more > familiar with this particular code and can verify the performance is > still ok for high speed networks. Yes, I'll take a look at this, and updated the patch accordingly (and re-run the performance tests). -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer

Re: [PATCH 2/5] mm/page_alloc: Add a bulk page allocator

ally differs slightly in different parts of the kernel. I started in networking area of the kernel, and I was also surprised when I started working in MM area that the coding style differs. I can tell you that the indentation style Mel choose is consistent with the code styling in MM area. I usually respect that even-though I prefer the networking style as I was "raised" with that style. -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer

Re: [PATCH 2/5] mm/page_alloc: Add a bulk page allocator

ld be checked). It would > need a lot of review and testing. The result of the API is to deliver pages as a double-linked list via LRU (page->lru member). If you are planning to use llist, then how to handle this API change later? Have you notice that the two users store the struct-page pointers in an array? We could have the caller provide the array to store struct-page pointers, like we do with kmem_cache_alloc_bulk API. You likely have good reasons for returning the pages as a list (via lru), as I can see/imagine that there are some potential for grabbing the entire PCP-list. > > > + list_add(&page->lru, alloc_list); > > > + alloced++; > > > + } > > > + > > > + if (!alloced) > > > + goto failed_irq; > > > + > > > + if (alloced) { > > > + __count_zid_vm_events(PGALLOC, zone_idx(zone), > > > alloced); > > > + zone_statistics(zone, zone); > > > + } > > > + > > > + local_irq_restore(flags); > > > + > > > + return alloced; > > > + > > > +failed_irq: > > > + local_irq_restore(flags); > > > + > > > +failed: > > > > Might we need some counter to show how often this path happens? > > > > I think that would be overkill at this point. It only gives useful > information to a developer using the API for the first time and that > can be done with a debugging patch (or probes if you're feeling > creative). I'm already unhappy with the counter overhead in the page > allocator. zone_statistics in particular has no business being an > accurate statistic. It should have been a best-effort counter like > vm_events that does not need IRQs to be disabled. If that was a > simply counter as opposed to an accurate statistic then a failure > counter at failed_irq would be very cheap to add. -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer

[PATCH bpf V3 2/2] selftests/bpf: Tests using bpf_check_mtu BPF-helper input mtu_len param

Add tests that use mtu_len as input parameter in BPF-helper bpf_check_mtu(). The BPF-helper is avail from both XDP and TC context. Add two tests per context, one that tests below MTU and one that exceeds the MTU. Signed-off-by: Jesper Dangaard Brouer Acked-by: John Fastabend --- tools/testing

[PATCH bpf V3 1/2] bpf: BPF-helper for MTU checking add length input

n.c Signed-off-by: Jesper Dangaard Brouer Acked-by: John Fastabend --- include/uapi/linux/bpf.h | 16 +++- net/core/filter.c| 12 ++-- 2 files changed, 21 insertions(+), 7 deletions(-) diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h index 79c893310

[PATCH bpf V3 0/2] bpf: Updates for BPF-helper bpf_check_mtu

to 34b2021cc616 ("bpf: Add BPF-helper for MTU checking"). [1] samples/bpf/xdp_fwd_kern.c --- V2: Fixed spelling and added ACKs from John Jesper Dangaard Brouer (2): bpf: BPF-helper for MTU checking add length input selftests/bpf: Tests using bpf_check_mtu BPF-helper input

Re: [PATCH bpf-next V2 0/2] bpf: Updates for BPF-helper bpf_check_mtu

On Fri, 26 Feb 2021 23:34:34 +0100 Daniel Borkmann wrote: > On 2/19/21 7:36 AM, Jesper Dangaard Brouer wrote: > > On Thu, 18 Feb 2021 12:49:53 +0100 > > Jesper Dangaard Brouer wrote: > > > >> The FIB lookup example[1] show how the IP-header field tot_len > &

Re: [PATCH v3 bpf-next] bpf: devmap: move drop error path to devmap for XDP_REDIRECT

o_net.c | 25 ---- > drivers/net/xen-netfront.c| 18 +-- > kernel/bpf/devmap.c | 30 --- > 22 files changed, 153 insertions(+), 200 deletions(-) Acked-by: Jesper Dangaard Brouer Acking cor

Re: [PATCH intel-net 1/3] i40e: move headroom initialization to i40e_configure_rx_ring

ving i40e_rx_offset() to i40e_configure_rx_ring() after > the flag setting. > > Fixes: f7bb0d71d658 ("i40e: store the result of i40e_rx_offset() onto > i40e_ring") > Reported-by: Jesper Dangaard Brouer > Co-developed-by: Jesper Dangaard Brouer > Signed-off-

Re: [PATCH 4/5] net: page_pool: refactor dma_map into own function page_pool_dma_map

On Wed, 3 Mar 2021 09:18:25 + Mel Gorman wrote: > On Tue, Mar 02, 2021 at 08:49:06PM +0200, Ilias Apalodimas wrote: > > On Mon, Mar 01, 2021 at 04:11:59PM +, Mel Gorman wrote: > > > From: Jesper Dangaard Brouer > > > > > > In preparation for next

Re: [PATCH v2 bpf-next] bpf: devmap: move drop error path to devmap for XDP_REDIRECT

On Mon, 1 Mar 2021 13:23:06 +0200 Shay Agroskin wrote: > Jesper Dangaard Brouer writes: > > > On Sun, 28 Feb 2021 23:27:25 +0100 > > Lorenzo Bianconi wrote: > > > >> > >drops = bq->count - sent; > >> > > -out: > >>

Re: Driver i40e have XDP-redirect bug

On Mon, 1 Mar 2021 13:18:32 +0100 Jesper Dangaard Brouer wrote: > Hi i40e-people + XDP-feature-people, > > The driver i40e have a XDP-redirect bug, where is it partly broken. It can > transmit a redirected xdp_frame (from another driver). But broken when > redirecting a xd

[PATCH RFC V2 net-next 0/2] Use bulk order-0 page allocator API for page_pool

carry these patches? (to keep it together with the alloc_pages_bulk API) --- Jesper Dangaard Brouer (2): net: page_pool: refactor dma_map into own function page_pool_dma_map net: page_pool: use alloc_pages_bulk in refill code path net/core/page_po

[PATCH RFC V2 net-next 2/2] net: page_pool: use alloc_pages_bulk in refill code path

(3,677,958 pps -> 4,368,926 pps). [1] https://github.com/xdp-project/xdp-project/blob/master/areas/mem/page_pool06_alloc_pages_bulk.org Signed-off-by: Jesper Dangaard Brouer --- net/core/page_pool.c | 63 -- 1 file changed, 40 insertions(+),

[PATCH RFC V2 net-next 1/2] net: page_pool: refactor dma_map into own function page_pool_dma_map

In preparation for next patch, move the dma mapping into its own function, as this will make it easier to follow the changes. V2: make page_pool_dma_map return boolean (Ilias) Signed-off-by: Jesper Dangaard Brouer --- net/core/page_pool.c | 45 ++--- 1

Driver i40e have XDP-redirect bug

redirect starts working again. I will continue to find the offending commit... (to-be-continued) (p.s. testing on net-next on top of commit d310ec03a34e92). -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer

Re: [PATCH v2 bpf-next] bpf: devmap: move drop error path to devmap for XDP_REDIRECT

ven w/o the 'if' condition ? > > it is just an optimization to avoid the for loop instruction if sent = > bq->count True, and I like this optimization. It will affect how the code layout is (and thereby I-cache usage). -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer

Re: [PATCH bpf-next V2 1/2] bpf: BPF-helper for MTU checking add length input

On Sat, 27 Feb 2021 00:36:02 +0100 Daniel Borkmann wrote: > On 2/18/21 12:49 PM, Jesper Dangaard Brouer wrote: > > The FIB lookup example[1] show how the IP-header field tot_len > > (iph->tot_len) is used as input to perform the MTU check. > > > > This patch exten

Re: [PATCH RFC net-next 3/3] mm: make zone->free_area[order] access faster

On Thu, 25 Feb 2021 15:38:15 + Mel Gorman wrote: > On Thu, Feb 25, 2021 at 04:16:33PM +0100, Jesper Dangaard Brouer wrote: > > > On Wed, Feb 24, 2021 at 07:56:51PM +0100, Jesper Dangaard Brouer wrote: > > > > Avoid multiplication (imul) operations when accessing:

Re: [PATCH RFC net-next 2/3] net: page_pool: use alloc_pages_bulk in refill code path

On Wed, 24 Feb 2021 22:15:22 +0200 Ilias Apalodimas wrote: > Hi Jesper, > > On Wed, Feb 24, 2021 at 07:56:46PM +0100, Jesper Dangaard Brouer wrote: > > There are cases where the page_pool need to refill with pages from the > > page allocator. Some workloads cause the page_

Re: [PATCH bpf-next v4 1/2] bpf, xdp: make bpf_redirect_map() a map operation

t; > gives 24.8 Mpps. > > > > > > Now, xdp_redirect_map. Same NIC, two ports, receive from port A, > > redirect to port B: > > > > baseline:14.3 Mpps > > this series: 15.4 Mpps > > > > which is almost 8%! > > Or 5 ns difference: >

Re: [PATCH bpf-next v4 1/2] bpf, xdp: make bpf_redirect_map() a map operation

gt; functions are now local to the map implementation files, which removes > > one additional function call. > > > > Signed-off-by: Björn Töpel > > Nice! I agree that this is a much nicer approach! :) I agree :-) Acked-by: Jesper Dangaard Brouer -- Best regards

Re: [PATCH bpf-next v4 1/2] bpf, xdp: make bpf_redirect_map() a map operation

leneck for CPUMAP is the remote CPU dequeue. You should still be able to see that RX-side performance improve, and that should be enough (even-though packets are dropped before reaching remote CPU). I'm not going to ask you to test scale out to more CPUs. -- Best regards, Jesper Dang

Re: [PATCH v2 net-next] virtio-net: support XDP_TX when not more queues

slower on this device due to too few free TX rings available. In the future, we can mark a XDP features flag that this device is operating in a slower "locked" Tx mode. > > old_prog = rtnl_dereference(vi->rq[0].xdp_prog); > if (!prog && !old_prog) -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer

Re: [PATCH RFC net-next 3/3] mm: make zone->free_area[order] access faster

> > On Wed, Feb 24, 2021 at 07:56:51PM +0100, Jesper Dangaard Brouer wrote: > > Avoid multiplication (imul) operations when accessing: > > zone->free_area[order].nr_free > > > > This was really tricky to find. I was puzzled why perf reported that > > r

[PATCH RFC net-next 3/3] mm: make zone->free_area[order] access faster

exchange a 3-cycle imul with a 1-cycle shl, saving 2-cycles. It does trade some space to do this. Used: gcc (GCC) 9.3.1 20200408 (Red Hat 9.3.1-2) Signed-off-by: Jesper Dangaard Brouer --- include/linux/mmzone.h |6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/inclu

[PATCH RFC net-next 2/3] net: page_pool: use alloc_pages_bulk in refill code path

(3,677,958 pps -> 4,368,926 pps). [1] https://github.com/xdp-project/xdp-project/blob/master/areas/mem/page_pool06_alloc_pages_bulk.org Signed-off-by: Jesper Dangaard Brouer --- net/core/page_pool.c | 65 -- 1 file changed, 41 insertions(+),

[PATCH RFC net-next 0/3] Use bulk order-0 page allocator API for page_pool

This is a followup to Mel Gorman's patchset: - Message-Id: <20210224102603.19524-1-mgor...@techsingularity.net> - https://lore.kernel.org/netdev/20210224102603.19524-1-mgor...@techsingularity.net/ Showing page_pool usage of the API for alloc_pages_bulk(). --- Jesper Dangaar

[PATCH RFC net-next 1/3] net: page_pool: refactor dma_map into own function page_pool_dma_map

In preparation for next patch, move the dma mapping into its own function, as this will make it easier to follow the changes. Signed-off-by: Jesper Dangaard Brouer --- net/core/page_pool.c | 49 + 1 file changed, 29 insertions(+), 20 deletions

Re: [RFC PATCH 0/3] Introduce a bulk order-0 page allocator for sunrpc

to any other users. If you change local_irq_save(flags) to local_irq_disable() then you can likely get better performance for 1 page requests via this API. This limits the API to be used in cases where IRQs are enabled (which is most cases). (For my use-case I will not do 1 page requests). -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer

Re: [PATCHv2 bpf-next] bpf: remove blank line in bpf helper description

e/uapi/linux/bpf.h | 1 - > 2 files changed, 2 deletions(-) Acked-by: Jesper Dangaard Brouer > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h > index 4c24daa43bac..79c893310492 100644 > --- a/include/uapi/linux/bpf.h > +++ b/include/uapi/linux/bpf.h > @@ -3850,7

Re: [PATCH bpf-next] bpf: fix missing * in bpf.h

functions. > > Fixes: 34b2021cc616 ("bpf: Add BPF-helper for MTU checking") > Signed-off-by: Hangbin Liu > --- > include/uapi/linux/bpf.h | 2 +- > tools/include/uapi/linux/bpf.h | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) Thanks for fixing tha

Re: [PATCH RFC net-next] mlx5: fix for crash on net-next

On Tue, 23 Feb 2021 10:28:35 +0200 Tariq Toukan wrote: > On 2/22/2021 9:50 PM, Jesper Dangaard Brouer wrote: > > Net-next at commit d310ec03a34e ("Merge tag 'perf-core-2021-02-17') > > > > There is a divide error in drivers/net/ethernet/mellanox/mlx5/

Re: alloc_pages_bulk()

pcp, pcp_list); > > > if (!page) > > > break; > > > > The NFS server is considerably more stable now. Thank you! > > > > Thanks for testing! I've done some testing here: https://github.com/xdp-project/xdp-project/blob/master/areas/mem/page_pool06_alloc_pages_bulk.org Performance summary: - Before: 3,677,958 pps - After : 4,066,028 pps I'll describe/show the page_pool changes tomorrow. -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer

[PATCH RFC net-next] mlx5: fix for crash on net-next

lows me to boot with mlx5 driver enabled. Signed-off-by: Jesper Dangaard Brouer --- drivers/net/ethernet/mellanox/mlx5/core/en_tx.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_tx.c b/drivers/net/ethernet/mellanox/m

Re: alloc_pages_bulk()

On Mon, 22 Feb 2021 09:42:56 + Mel Gorman wrote: > On Mon, Feb 15, 2021 at 05:10:38PM +0100, Jesper Dangaard Brouer wrote: > > > > On Mon, 15 Feb 2021 12:00:56 + > > Mel Gorman wrote: > > > > > On Thu, Feb 11, 2021 at 01:26:28PM

Re: [PATCH bpf-next v3 2/2] bpf, xdp: restructure redirect actions

-- > kernel/bpf/cpumap.c| 1 - > kernel/bpf/devmap.c| 1 - > net/core/filter.c | 165 - > net/xdp/xskmap.c | 1 - > 7 files changed, 122 insertions(+), 124 deletions(-) I like it! :-) Acked-by: Jesper Dangaard Brouer -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer

Re: [PATCH bpf-next v3 1/2] bpf, xdp: per-map bpf_redirect_map functions for XDP

rnel/bpf/verifier.c | 17 > net/core/filter.c | 61 -- > 7 files changed, 78 insertions(+), 41 deletions(-) Love it! :-) Acked-by: Jesper Dangaard Brouer -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer

Re: [PATCH net] dpaa_eth: fix the access method for the dpaa_napi_portal

y: Sascha Hauer > Signed-off-by: Camelia Groza > --- > drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) LGTM Acked-by: Jesper Dangaard Brouer -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel

Re: [PATCH bpf-next V2 0/2] bpf: Updates for BPF-helper bpf_check_mtu

On Thu, 18 Feb 2021 12:49:53 +0100 Jesper Dangaard Brouer wrote: > The FIB lookup example[1] show how the IP-header field tot_len > (iph->tot_len) is used as input to perform the MTU check. The recently > added MTU check helper bpf_check_mtu() should also support this type &g

[PATCH bpf-next V2 2/2] selftests/bpf: Tests using bpf_check_mtu BPF-helper input mtu_len param

Add tests that use mtu_len as input parameter in BPF-helper bpf_check_mtu(). The BPF-helper is avail from both XDP and TC context. Add two tests per context, one that tests below MTU and one that exceeds the MTU. Signed-off-by: Jesper Dangaard Brouer Acked-by: John Fastabend --- tools/testing

[PATCH bpf-next V2 1/2] bpf: BPF-helper for MTU checking add length input

n.c Signed-off-by: Jesper Dangaard Brouer Acked-by: John Fastabend --- include/uapi/linux/bpf.h | 17 +++-- net/core/filter.c| 12 ++-- 2 files changed, 21 insertions(+), 8 deletions(-) diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h index 4c24daa43

[PATCH bpf-next V2 0/2] bpf: Updates for BPF-helper bpf_check_mtu

to 34b2021cc616 ("bpf: Add BPF-helper for MTU checking"). [1] samples/bpf/xdp_fwd_kern.c V2: Fixed spelling and added ACKs from John --- Jesper Dangaard Brouer (2): bpf: BPF-helper for MTU checking add length input selftests/bpf: Tests using bpf_check_mtu BPF-helper input

Re: [PATCH] Revert "dpaa_eth: add XDP_REDIRECT support"

revert the patch for now. Can we please get a response from NXP people? Are you saying XDP_REDIRECT feature is completely broken on dpaa driver? (I only have access to dpaa2 hardware) -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer

[PATCH bpf-next V1 1/2] bpf: BPF-helper for MTU checking add length input

n.c Signed-off-by: Jesper Dangaard Brouer --- include/uapi/linux/bpf.h | 17 +++-- net/core/filter.c| 12 ++-- 2 files changed, 21 insertions(+), 8 deletions(-) diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h index 4c24daa43bac..9c8aa50dc8a5 100644 --

[PATCH bpf-next V1 2/2] selftests/bpf: Tests using bpf_check_mtu BPF-helper input mtu_len param

Add tests that use mtu_len as input parameter in BPF-helper bpf_check_mtu(). The BPF-helper is avail from both XDP and TC context. Add two tests per context, one that tests below MTU and one that exceeds the MTU. Signed-off-by: Jesper Dangaard Brouer --- tools/testing/selftests/bpf/prog_tests

[PATCH bpf-next V1 0/2] bpf: Updates for BPF-helper bpf_check_mtu

to 34b2021cc616 ("bpf: Add BPF-helper for MTU checking"). [1] samples/bpf/xdp_fwd_kern.c --- Jesper Dangaard Brouer (2): bpf: BPF-helper for MTU checking add length input selftests/bpf: Tests using bpf_check_mtu BPF-helper input mtu_len param include/uap

Re: [PATCH net-next V1] net: followup adjust net_device layout for cacheline usage

On Fri, 12 Feb 2021 18:03:44 +0100 Eric Dumazet wrote: > On 2/12/21 2:50 PM, Jesper Dangaard Brouer wrote: > > As Eric pointed out in response to commit 28af22c6c8df ("net: adjust > > net_device layout for cacheline usage") the netdev_features_t members > > want

Re: [PATCH net-next V1] net: adjust net_device layout for cacheline usage

; > Either way is fine by me, we can always preserve meaningful comments > inline without the kdoc decorator. I agree that removing this kdoc makes sense. But as Jakub says we should preserve meaningful comments inline. I'll add this task to my TODO list, but anyone feel

Re: [PATCH net-next V1] net: adjust net_device layout for cacheline usage

On Fri, 29 Jan 2021 15:00:58 +0100 Jesper Dangaard Brouer wrote: > On Fri, 29 Jan 2021 14:33:02 +0100 > Eric Dumazet wrote: > > > On 1/26/21 6:39 PM, Jesper Dangaard Brouer wrote: > > > The current layout of net_device is not optimal for cacheline usage. >

[PATCH net-next V1] net: followup adjust net_device layout for cacheline usage

ing member gso_partial_features to be closer to member gso_max_segs. (see usage in gso_features_check()). Suggested-by: Eric Dumazet Signed-off-by: Jesper Dangaard Brouer --- include/linux/netdevice.h | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/include/linux/netdevice.h

Re: [EXT] Re: [PATCH v2 net-next 1/2] samples: pktgen: allow to specify delay parameter via new opt

ng "append", you can disable that shell feature in your script (instead of removing the line from functions.sh). -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer

  1   2   3   4   5   6   7   8   9   10   >