Hi Matthew,
[...]
>
> And the contents of this page already came from that device ... if it
> wanted to write bad data, it could already have done so.
>
> > > > (3) The page_pool is optimized for refcnt==1 case, and AFAIK TCP-RX
> > > > zerocopy will bump the refcnt, which means the page_pool
On Mon, Apr 19, 2021 at 09:21:55AM -0700, Shakeel Butt wrote:
> On Mon, Apr 19, 2021 at 8:43 AM Ilias Apalodimas
> wrote:
> >
> [...]
> > > Pages mapped into the userspace have their refcnt elevated, so the
> > > page_ref_count() check by the drivers indica
Hi Shakeel,
On Mon, Apr 19, 2021 at 07:57:03AM -0700, Shakeel Butt wrote:
> On Sun, Apr 18, 2021 at 10:12 PM Ilias Apalodimas
> wrote:
> >
> > On Wed, Apr 14, 2021 at 01:09:47PM -0700, Shakeel Butt wrote:
> > > On Wed, Apr 14, 2021 at 12:42 PM Jesper D
Hi Christoph,
On Mon, Apr 19, 2021 at 08:34:41AM +0200, Christoph Hellwig wrote:
> On Fri, Apr 16, 2021 at 04:27:55PM +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
> > >
On Wed, Apr 14, 2021 at 01:09:47PM -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 used.
> > >
> > > Yes it can, since it's going to be
On Sat, Apr 17, 2021 at 09:22:40PM +0100, Matthew Wilcox wrote:
> On Sat, Apr 17, 2021 at 09:32:06PM +0300, Ilias Apalodimas wrote:
> > > +static inline void page_pool_set_dma_addr(struct page *page, dma_addr_t
> > > addr)
> > > +{
> > > + page->dma_add
Hi Matthew,
On Sat, Apr 17, 2021 at 03:45:22AM +0100, Matthew Wilcox wrote:
>
> Replacement patch to fix compiler warning.
>
> From: "Matthew Wilcox (Oracle)"
> Date: Fri, 16 Apr 2021 16:34:55 -0400
> Subject: [PATCH 1/2] mm: Fix struct page layout on 32-bit systems
> To: bro...@redhat.com
>
On Wed, Apr 14, 2021 at 12:50:52PM +0100, Matthew Wilcox wrote:
> On Wed, Apr 14, 2021 at 10:10:44AM +0200, Jesper Dangaard Brouer wrote:
> > Yes, indeed! - And very frustrating. It's keeping me up at night.
> > I'm dreaming about 32 vs 64 bit data structures. My fitbit stats tell
> > me that I
Hi Shakeel,
On Sat, Apr 10, 2021 at 10:42:30AM -0700, Shakeel Butt wrote:
> On Sat, Apr 10, 2021 at 9:16 AM Ilias Apalodimas
> wrote:
> >
> > Hi Matthew
> >
> > On Sat, Apr 10, 2021 at 04:48:24PM +0100, Matthew Wilcox wrote:
> > > On Sat, Apr 10, 2021
Hi Matthew
On Sat, Apr 10, 2021 at 04:48:24PM +0100, Matthew Wilcox wrote:
> On Sat, Apr 10, 2021 at 12:37:58AM +0200, Matteo Croce wrote:
> > This is needed by the page_pool to avoid recycling a page not allocated
> > via page_pool.
>
> Is the PageType mechanism more appropriate to your needs?
+CC Grygorii for the cpsw part as Ivan's email is not valid anymore
Thanks for catching this. Interesting indeed...
On Sat, 10 Apr 2021 at 09:22, Jesper Dangaard Brouer wrote:
>
> On Sat, 10 Apr 2021 03:43:13 +0100
> Matthew Wilcox wrote:
>
> > On Sat, Apr 10, 2021 at 06:45:35AM +0800, kernel
Hi Matteo,
[...]
> +bool page_pool_return_skb_page(void *data);
> +
> struct page_pool *page_pool_create(const struct page_pool_params *params);
>
> #ifdef CONFIG_PAGE_POOL
> @@ -243,4 +247,13 @@ static inline void page_pool_ring_unlock(struct
> page_pool *pool)
>
On Fri, Apr 09, 2021 at 12:29:29PM -0700, Jakub Kicinski wrote:
> 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
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
> > Signed-off-by: Ilias Apalodimas
>
> Checkpatch says we need
On Wed, Mar 24, 2021 at 10:28:35AM +0100, Lorenzo Bianconi wrote:
> [...]
> > > diff --git a/drivers/net/ethernet/marvell/mvneta.c
> > > b/drivers/net/ethernet/marvell/mvneta.c
> > > index a635cf84608a..8b3250394703 100644
> > > --- a/drivers/net/ethernet/marvell/mvneta.c
> > > +++
Hi Alexander,
On Tue, Mar 23, 2021 at 08:03:46PM +, Alexander Lobakin wrote:
> From: Ilias Apalodimas
> Date: Tue, 23 Mar 2021 19:01:52 +0200
>
> > On Tue, Mar 23, 2021 at 04:55:31PM +, Alexander Lobakin wrote:
> > > > > > > >
> >
>
On Tue, Mar 23, 2021 at 04:55:31PM +, Alexander Lobakin wrote:
> > > > > >
[...]
> > > > >
> > > > > Thanks for the testing!
> > > > > Any chance you can get a perf measurement on this?
> > > >
> > > > I guess you mean perf-report (--stdio) output, right?
> > > >
> > >
> > > Yea,
> > > As
On Tue, Mar 23, 2021 at 05:04:47PM +0100, Jesper Dangaard Brouer wrote:
> On Tue, 23 Mar 2021 17:47:46 +0200
> Ilias Apalodimas wrote:
>
> > On Tue, Mar 23, 2021 at 03:41:23PM +, Alexander Lobakin wrote:
> > > From: Matteo Croce
> > > Date
skb_frag_unref
> > users, and 5,6 enable the recycling on two drivers.
> >
> > In the last two patches I reported the improvement I have with the series.
> >
> > The recycling as is can't be used with drivers like mlx5 which do page
> > split,
> > but this is docum
Hi David,
On Tue, Mar 23, 2021 at 08:57:57AM -0600, David Ahern wrote:
> On 3/22/21 11:02 AM, Matteo Croce wrote:
> > From: Matteo Croce
> >
> > This series enables recycling of the buffers allocated with the page_pool
> > API.
> > The first two patches are just prerequisite to save space in
[...]
> 6. return last_page
>
> > + /* Remaining pages store in alloc.cache */
> > + list_for_each_entry_safe(page, next, _list, lru) {
> > + list_del(>lru);
> > + if ((pp_flags & PP_FLAG_DMA_MAP) &&
> > + unlikely(!page_pool_dma_map(pool,
On Fri, Mar 12, 2021 at 05:29:20PM +0530, Sumit Garg wrote:
> On Fri, 12 Mar 2021 at 01:59, Hector Martin wrote:
> >
> > On 11/03/2021 23.31, Linus Walleij wrote:
> > > I understand your argument, is your position such that the nature
> > > of the hardware is such that community should leave this
held 'in-flight' */
> pool->pages_state_hold_cnt++;
> - trace_page_pool_state_hold(pool, page, pool->pages_state_hold_cnt);
> + trace_page_pool_state_hold(pool, first_page,
> pool->pages_state_hold_cnt);
>
> /* When page just alloc'ed is should/must have refcnt 1. */
> - return page;
> + return first_page;
> }
>
> /* For using page_pool replace: alloc_pages() API calls, but provide
> --
> 2.26.2
>
Reviewed-by: Ilias Apalodimas
> - page_pool_dma_sync_for_device(pool, page, pool->p.max_len);
> -
> -skip_dma_map:
> /* Track how many pages are held 'in-flight' */
> pool->pages_state_hold_cnt++;
> -
> trace_page_pool_state_hold(pool, page, pool->pages_state_hold_cnt);
>
> /* When page just alloc'ed is should/must have refcnt 1. */
> --
> 2.26.2
>
Otherwise
Reviewed-by: Ilias Apalodimas
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_pool to release pages
> instead of recycling these pages.
>
> For these workload it can
On Wed, Feb 24, 2021 at 07:56:41PM +0100, Jesper Dangaard Brouer wrote:
> 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
/* Read barrier done in page_ref_count / READ_ONCE */
>
> if (pool->p.flags & PP_FLAG_DMA_SYNC_DEV)
> --
> 2.30.0
>
>
Reviewed-by: Ilias Apalodimas
On Mon, Dec 14, 2020 at 06:39:21PM +0100, Heinrich Schuchardt wrote:
> On 14.12.20 18:01, Ilias Apalodimas wrote:
> > At the moment the EFI stub tries to load an initrd from the
> > cmdline provided option only if the LoadFile2 protocol does not exist
> > on t
respect the
firmware in case it returns EFI_NOT_FOUND. This way we can load the
cmdline provided initrd.
Signed-off-by: Ilias Apalodimas
---
drivers/firmware/efi/libstub/efi-stub-helper.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/efi/libstub/efi
u
Reported-by: Jiri Olsa
Co-developed-by: Jean-Philippe Brucker
Signed-off-by: Jean-Philippe Brucker
Co-developed-by: Yauheni Kaliuta
Signed-off-by: Yauheni Kaliuta
Signed-off-by: Ilias Apalodimas
---
Changes since v1:
- Added Co-developed-by, Reported-by and Fixes tags correctly
- Descr
Hi Will,
On Tue, Sep 15, 2020 at 02:11:03PM +0100, Will Deacon wrote:
[...]
> > continue;
> > }
> > - if (ctx->image == NULL)
> > - ctx->offset[i] = ctx->idx;
> > if (ret)
> > return ret;
> > }
> > +
On Tue, Sep 15, 2020 at 02:11:03PM +0100, Will Deacon wrote:
> Hi Ilias,
>
> On Mon, Sep 14, 2020 at 07:03:55PM +0300, Ilias Apalodimas wrote:
> > Running the eBPF test_verifier leads to random errors looking like this:
> >
> > [ 6525.735488] Unexpected
Hi Will,
On Tue, Sep 15, 2020 at 03:17:08PM +0100, Will Deacon wrote:
> On Tue, Sep 15, 2020 at 04:53:44PM +0300, Ilias Apalodimas wrote:
> > On Tue, Sep 15, 2020 at 02:11:03PM +0100, Will Deacon wrote:
> > > Hi Ilias,
> > >
> > > On Mon, Sep 14, 2020 at 07:0
On Mon, Sep 14, 2020 at 11:52:16AM -0700, Xi Wang wrote:
> On Mon, Sep 14, 2020 at 11:28 AM Ilias Apalodimas
> wrote:
> > Even if that's true, is any reason at all why we should skip the first
> > element
> > of the array, that's now needed since 7c2e988f400 t
Hi Luke,
On Mon, Sep 14, 2020 at 11:21:58AM -0700, Luke Nelson wrote:
> On Mon, Sep 14, 2020 at 11:08 AM Xi Wang wrote:
> > I don't think there's some consistent semantics of "offsets" across
> > the JITs of different architectures (maybe it's good to clean that
> > up). RV64 and RV32 JITs are
Hi Xi,
On Mon, Sep 14, 2020 at 11:08:13AM -0700, Xi Wang wrote:
> On Mon, Sep 14, 2020 at 10:55 AM Ilias Apalodimas
> wrote:
> > We've briefly discussed this approach with Yauheni while coming up with the
> > posted patch.
> > I think that contructing the array corr
On Mon, Sep 14, 2020 at 10:47:33AM -0700, Xi Wang wrote:
> On Mon, Sep 14, 2020 at 10:03 AM Ilias Apalodimas
> wrote:
> > Naresh from Linaro reported it during his tests on 5.8-rc1 as well [1].
> > I've included both Jiri and him on the v2 as reporters.
> >
> > [1] h
On Mon, Sep 14, 2020 at 06:12:34PM +0200, Jesper Dangaard Brouer wrote:
>
> On Mon, 14 Sep 2020 15:01:15 +0100 Will Deacon wrote:
>
> > Hi Ilias,
> >
> > On Mon, Sep 14, 2020 at 04:23:50PM +0300, Ilias Apalodimas wrote:
> > > On Mon, Sep 14, 2020 at 03:3
loped-by: Jean-Philippe Brucker
Signed-off-by: Jean-Philippe Brucker
Co-developed-by: Yauheni Kaliuta
Signed-off-by: Yauheni Kaliuta
Signed-off-by: Ilias Apalodimas
---
Changes since v1:
- Added Co-developed-by, Reported-by and Fixes tags correctly
- Describe the expected context of ctx
Hi Will,
On Mon, Sep 14, 2020 at 03:01:15PM +0100, Will Deacon wrote:
> Hi Ilias,
>
[...]
> > > >
> > > > No Fixes: tag?
> > >
> > > I'll re-spin and apply one
> > >
> > Any suggestion on any Fixes I should apply? The original code was 'correct'
> > and
> > broke only when bounded loops
Hi Will,
On Mon, Sep 14, 2020 at 03:35:04PM +0300, Ilias Apalodimas wrote:
> On Mon, Sep 14, 2020 at 01:20:43PM +0100, Will Deacon wrote:
> > On Mon, Sep 14, 2020 at 11:36:21AM +0300, Ilias Apalodimas wrote:
> > > Running the eBPF test_verifier leads to random e
On Mon, Sep 14, 2020 at 01:20:43PM +0100, Will Deacon wrote:
> On Mon, Sep 14, 2020 at 11:36:21AM +0300, Ilias Apalodimas wrote:
> > Running the eBPF test_verifier leads to random errors looking like this:
> >
> > [ 6525.735488] Unexpected kernel BRK exception at EL1
> &
>offset[] correctly in the first
place and account for the extra instruction while calculating the arm
instruction offsets.
Signed-off-by: Ilias Apalodimas
Signed-off-by: Jean-Philippe Brucker
Signed-off-by: Yauheni Kaliuta
---
arch/arm64/net/bpf_jit_comp.c | 23 +++
1 file change
On Tue, Jun 30, 2020 at 08:09:29PM +0200, Matteo Croce wrote:
> From: Matteo Croce
>
> Add XDP native support.
> By now only XDP_DROP, XDP_PASS and XDP_REDIRECT
> verdicts are supported.
>
> Co-developed-by: Sven Auhagen
> Signed-off-by: Sven Auhagen
> Signed-off-by: Matteo Croce
> ---
Hi Matteo,
Thanks for working on this!
On Tue, Jun 30, 2020 at 08:09:28PM +0200, Matteo Croce wrote:
> From: Matteo Croce
>
> Use the page_pool API for memory management. This is a prerequisite for
> native XDP support.
>
> Tested-by: Sven Auhagen
> Signed-off-by: Matteo Croce
> ---
>
Hi Alexander,
On Fri, Oct 11, 2019 at 03:27:50PM +0300, Alexander Lobakin wrote:
> Hi Ilias,
>
> Ilias Apalodimas wrote 11.10.2019 15:23:
> > Hi Alexander,
> >
> > On Thu, Oct 10, 2019 at 05:42:24PM +0300, Alexander Lobakin wrote:
> > > Hi Dave,
Hi Alexander,
On Thu, Oct 10, 2019 at 05:42:24PM +0300, Alexander Lobakin wrote:
> Hi Dave,
>
> This series was written as a continuation to commit 323ebb61e32b
> ("net: use listified RX for handling GRO_NORMAL skbs"), and also takes
> an advantage of listified Rx for GRO. This time, however,
libpf targets
> samples/bpf: provide C/LDFLAGS to libbpf
> samples/bpf: add sysroot support
> samples/bpf: add preparation steps and sysroot info to readme
>
> samples/bpf/Makefile | 164 ++
> samples/bpf/Makefile.target | 75
> samples/bpf/README.rst| 41 -
> tools/lib/bpf/Makefile| 23 +--
> .../bpf/{test_libbpf.cpp => test_libbpf.c}| 14 +-
> 5 files changed, 218 insertions(+), 99 deletions(-)
> create mode 100644 samples/bpf/Makefile.target
> rename tools/lib/bpf/{test_libbpf.cpp => test_libbpf.c} (61%)
>
> --
> 2.17.1
>
For native compilation on x86_64 and aarch64
Tested-by: Ilias Apalodimas
Hi Jon, Jose,
On Thu, Jul 25, 2019 at 10:45:46AM +0100, Jon Hunter wrote:
>
> On 25/07/2019 08:44, Jose Abreu wrote:
>
> ...
>
> > OK. Can you please test what Ilias mentioned ?
> >
> > Basically you can hard-code the order to 0 in
> > alloc_dma_rx_desc_resources():
> > - pp_params.order =
Jose,
> From: Ilias Apalodimas
> Date: Jul/24/2019, 09:54:27 (UTC+00:00)
>
> > Hi David,
> >
> > > From: Jon Hunter
> > > Date: Tue, 23 Jul 2019 13:09:00 +0100
> > >
> > > > Setting "iommu.passthrough=1" works for me.
Hi David,
> From: Jon Hunter
> Date: Tue, 23 Jul 2019 13:09:00 +0100
>
> > Setting "iommu.passthrough=1" works for me. However, I am not sure where
> > to go from here, so any ideas you have would be great.
>
> Then definitely we are accessing outside of a valid IOMMU mapping due
> to the
On Thu, Jul 18, 2019 at 07:48:04AM +, Jose Abreu wrote:
> From: Jon Hunter
> Date: Jul/17/2019, 19:58:53 (UTC+00:00)
>
> > Let me know if you have any thoughts.
>
> Can you try attached patch ?
>
The log says someone calls panic() right?
Can we trye and figure were that happens during
Hello,
> From: Jose Abreu
> Date: Mon, 8 Jul 2019 16:08:07 +
>
> > From: Ilias Apalodimas | Date: Fri, Jul
> > 05, 2019 at 16:24:53
> >
> >> Well ideally we'd like to get the change in before the merge window
> >> ourselves,
> >>
Hi Jose,
On Fri, Jul 05, 2019 at 03:21:16PM +, Jose Abreu wrote:
> From: Ilias Apalodimas
>
> > I think this look ok for now. One request though, on page_pool_free
>
> Thanks for the review!
>
> > A patch currently under review will slightly change that [1
> Changes from v1:
> - Use page_pool_get_dma_addr() (Jesper)
> - Add a comment (Jesper)
> - Add page_pool_free() call (Jesper)
> - Reintroduce sync_single_for_device (Arnd / Ilias)
>
> Signed-off-by: Jose Abreu
> Cc: Joao Pinto
> Cc: David S. Miller
&
Hi Ivan,
>
> Have trouble with inet today...I will pick up it as my changes depend on it.
> And send probably in couple hours after verification.
Maybe you'd like to add your signed-off on this one since it was based on your
patchset?
Regards
/Ilias
, "API usage violation");
> WARN(!ptr_ring_empty(>ring), "ptr_ring is not empty");
>
> diff --git a/net/core/xdp.c b/net/core/xdp.c
> index b29d7b513a18..57c2317d9ce5 100644
> --- a/net/core/xdp.c
> +++ b/net/core/xdp.c
> @@ -370,6 +370,15 @@ int xdp_rxq_info_reg_mem_model(struct xdp_rxq_info
> *xdp_rxq,
> goto err;
> }
>
> + if (type == MEM_TYPE_PAGE_POOL) {
> + if (page_pool_get(xdp_alloc->page_pool) > 2) {
> + WARN(1, "API misuse, argue to enable use-case");
> + page_pool_put(xdp_alloc->page_pool);
> + errno = -EINVAL;
> + goto err;
> + }
> + }
> +
> mutex_unlock(_id_lock);
>
> trace_mem_connect(xdp_alloc, xdp_rxq);
>
For the netsec and page_pool part
Reviewed-by: Ilias Apalodimas
Hi Jose,
> Thank you all for your review comments !
>
> From: Ilias Apalodimas
>
> > That's why i was concerned on what will happen on > 1000b frames and what
> > the
> > memory pressure is going to be.
> > The trade off here is copying vs mappin
On Thu, Jul 04, 2019 at 02:14:28PM +0200, Arnd Bergmann wrote:
> On Thu, Jul 4, 2019 at 12:31 PM Ilias Apalodimas
> wrote:
> > > On Wed, 3 Jul 2019 12:37:50 +0200
> > > Jose Abreu wrote:
>
> > 1. page pool allocs packet. The API doesn't sync but i *think* you
Hi Jesper,
> On Thu, 4 Jul 2019 10:13:37 +
> Jose Abreu wrote:
> > > The page_pool DMA mapping cannot be "kept" when page traveling into the
> > > network stack attached to an SKB. (Ilias and I have a long term plan[1]
> > > to allow this, but you cannot do it ATM).
> >
> > The reason I
On Thu, Jul 04, 2019 at 10:13:37AM +, Jose Abreu wrote:
> From: Jesper Dangaard Brouer
>
> > The page_pool DMA mapping cannot be "kept" when page traveling into the
> > network stack attached to an SKB. (Ilias and I have a long term plan[1]
> > to allow this, but you cannot do it ATM).
>
>
HI Jesper, Ivan,
> On Wed, 3 Jul 2019 12:37:50 +0200
> Jose Abreu wrote:
>
> > @@ -3547,6 +3456,9 @@ static int stmmac_rx(struct stmmac_priv *priv, int
> > limit, u32 queue)
> >
> > napi_gro_receive(>rx_napi, skb);
> >
> > +
On Thu, Jul 04, 2019 at 12:43:30PM +0300, Ivan Khoronzhuk wrote:
> On Thu, Jul 04, 2019 at 12:39:02PM +0300, Ilias Apalodimas wrote:
> >On Thu, Jul 04, 2019 at 11:19:39AM +0200, Jesper Dangaard Brouer wrote:
> >>On Wed, 3 Jul 2019 13:19:03 +0300
> >>Ivan Khoronzhuk
On Thu, Jul 04, 2019 at 11:19:39AM +0200, Jesper Dangaard Brouer wrote:
> On Wed, 3 Jul 2019 13:19:03 +0300
> Ivan Khoronzhuk wrote:
>
> > Add XDP support based on rx page_pool allocator, one frame per page.
> > Page pool allocator is used with assumption that only one rx_handler
> > is running
Hi Jesper,
Getting late here, i'll respond in detail tomorrow. One point though
[...]
>
> This special use-case, seems confined to your driver. And Ilias told me
> that XDP is not really a performance benefit for this driver as the HW
> PPS-limit is hit before the XDP and netstack limit. I ask,
On Mon, Jul 01, 2019 at 06:19:01PM +0200, Jesper Dangaard Brouer wrote:
> On Sun, 30 Jun 2019 20:23:48 +0300
> Ivan Khoronzhuk wrote:
>
> > +static int cpsw_ndev_create_xdp_rxq(struct cpsw_priv *priv, int ch)
> > +{
> > + struct cpsw_common *cpsw = priv->cpsw;
> > + int ret, new_pool =
On Thu, May 23, 2019 at 09:20:35PM +0300, Ivan Khoronzhuk wrote:
> Add XDP support based on rx page_pool allocator, one frame per page.
> Page pool allocator is used with assumption that only one rx_handler
> is running simultaneously. DMA map/unmap is reused from page pool
> despite there is no
Hi Ivan,
More XDP drivers, that's good!
> This patchset add XDP support for TI cpsw driver and base it on
> page_pool allocator. It was verified on af_xdp socket drop,
> af_xdp l2f, ebpf XDP_DROP, XDP_REDIRECT, XDP_PASS, XDP_TX.
>
> It was verified with following configs enabled:
> CONFIG_JIT=y
Hi Viresh, Gregory
On Mon, May 20, 2019 at 04:50:42PM +0530, Viresh Kumar wrote:
> On 25-04-19, 15:33, Ilias Apalodimas wrote:
> > Hi Viresh,
> >
> > > > > Also, during this week-end, Christian suggested that the issue might
> > > > > come from th
Hi Viresh,
> > > Also, during this week-end, Christian suggested that the issue might
> > > come from the AVS support.
> > >
> > > Could you disable it and check you still have the issue?
> > >
> > > For this, you just have to remove the avs node in
> > >
Hi Gregory,
> >>
> > [ 14.909524] clk_pm_cpu_set_parent old=28004840 -> val=0x600
> > load_level=0
> > [ 14.916424] clk_pm_cpu_set_parent old=2E004840 -> val=0x600 load_level=1
> > [ 14.923315] clk_pm_cpu_set_parent old=8880A8C0 -> val=0x600
> > load_level=2
> > [ 14.930572]
Hi Gregory,
> Hi Ilias,
>
> On jeu., mars 14 2019, Ilias Apalodimas wrote:
>
> > Hello Christian,
> >> Hi,
> >>
> >> I assume you use the 1000 MHz firmware. This does also not work on my Rev 7
> >> board. But I'm pretty sure this i
running at (frequency).
Ok, probably my bad here. By 'worked fine' i mean that this didn't lead to any
freezes or panics. I know the actual frequency wasn't set properly
Regards
/Ilias
>
> Regards,
> Christian
>
> Ilias Apalodimas schrieb am Do., 14. März
> 2019,
fine without the patches
Regards
/Ilias
>
> Ilias Apalodimas schrieb am Do., 14. März
> 2019, 13:15:
>
> > Hi Gregory,
> > > The clock parenting was not setup properly when DVFS was enabled. It was
> > > expected that the same clock source was used with and witho
CPU clocks source are not the default ones.
>
> Fixes: 92ce45fb875d ("cpufreq: Add DVFS support for Armada 37xx")
> Cc:
> Reported-by: Christian Neubert
> Reported-by: Ilias Apalodimas
> Signed-off-by: Gregory CLEMENT
> ---
> drivers/clk/mvebu/armada-37xx-periph
Hi Po,
> > >
> > > [Po] Ya, there are operations of switchdev. You may think that to add the
> > > TSN
> > configurations ops into switchdev operations. But we need to consider the
> > end-
> > station devices and switch all in the devices or in the TSN domain. The TSN
> > domain is the devices
Hi Po,
> > > > Some protocols target to configure the traffic class(like Qav CBS).
> > > > Some to config the port(like Qbv). But some for the whole ethernet
> > > > controller(like Qci, the control entries for the whole controller,
> > > > which input ports and which output ports).
> > >
> > >
Hi Po,
> > Hi Vinicius,
> >
> > Thank you very much for your feedback.
> >
> > I know the CBS is used to be most important part of AVB. And qdiscs is good
> > tool to configure qos.
> >
> > But as you know, the TSN family is a cluster of protocols and much
> > extending the AVB. The protocols
78 matches
Mail list logo
