Hi Igor,
> Here I understand your intention. You are trying to "offset" the placement of
> the packet data, and the restore it back when construction SKB.
Originally, I just added the skb_reserve call, but that broke everything. When
I looked at what the igb driver was doing, this approach seeme
Hi Igor,
> > With your solution, packets of size (AQ_CFG_RX_FRAME_MAX - AQ_SKB_PAD) up to
> > size of AQ_CFG_RX_FRAME_MAX will overwrite the area of page they designated
> > to. Ultimately, HW will do a memory corruption of next page.
>
> The code in aq_get_rxpages seems to suggest that multiple
The build_skb path fails to allow for an SKB header, but the hardware
buffer it is built around won't allow for this anyway.
Just always use the slower codepath that copies memory into an
allocated SKB.
Signed-off-by: Lincoln Ramsay
---
.../net/ethernet/aquantia/atlantic/aq_ring.c | 118 ++
The build_skb path fails to allow for an SKB header, but the hardware
buffer it is built around won't allow for this anyway.
Just always use the slower codepath that copies memory into an
allocated SKB.
Signed-off-by: Lincoln Ramsay
---
This patch is against the master branch rather than the 5.
> Ramsay, Lincoln wrote:
> > The build_skb path fails to allow for an SKB header, but the hardware
> > buffer it is built around won't allow for this anyway.
>
> What problem is being resolved here?
Sorry... Do I need to re-post the context? (I thought the reply hea
When performing IPv6 forwarding, there is an expectation that SKBs
will have some headroom. When forwarding a packet from the aquantia
driver, this does not always happen, triggering a kernel warning.
The build_skb path fails to allow for an SKB header, but the hardware
buffer it is built around w
When performing IPv6 forwarding, there is an expectation that SKBs
will have some headroom. When forwarding a packet from the aquantia
driver, this does not always happen, triggering a kernel warning.
aq_ring.c has this code (edited slightly for brevity):
if (buff->is_eop && buff->len <= AQ_CFG_R
> > I don't know about benefits/feasibility, but I did wonder if (in the event
> > that the "fast path" is possible), the dma_mapping could use an offset? The
> > page would include the skb header but the dma mapping would not. If that
> > was done though, only 1 RX frame would fit into the page
> Align continuations of the lines under '(' like:
Oh... I didn't run the patch checker over this revised patch. In this case, I
am only changing the leading indent. Am I still expected to satisfy the patch
checker?
The current patch is very clear about what is happening if you do a diff -w but
> (Next time please include in the subject the tree that you're targetting
> the patch)
I guess you mean like [PATCH master v5] ? Should I be targeting something other
than the master branch on the main git repo?
(https://github.com/torvalds/linux.git)
> please add a From: line at the beginning
> Yep, that could be the only way to fix this for now.
> Have you tried to estimate any performance drops from this?
Unfortunately, I am not in a very good position to do this. The 10G interfaces
on our device don't actually have enough raw PCI bandwidth available to hit 10G
transfer rates.
I d
From: Lincoln Ramsay
When performing IPv6 forwarding, there is an expectation that SKBs
will have some headroom. When forwarding a packet from the aquantia
driver, this does not always happen, triggering a kernel warning.
aq_ring.c has this code (edited slightly for brevity):
if (buff->is_eop &
When performing IPv6 forwarding, there is an expectation that SKBs
will have some headroom. When forwarding a packet from the aquantia
driver, this does not always happen, triggering a kernel warning.
It was observed that napi_alloc_skb and other ethernet drivers
reserve (NET_SKB_PAD + NET_IP_ALIG
13 matches
Mail list logo
