Yuval Mintz writes:
> Regardless, I'll give it a more thorough review tomorrow.
> [If those are all the "problems" we'll find with it, I don't think we'll
> need to re-spin this once more; that is, unless Dave insists]
As a follow up, here is a new version that fixes the style issues that Yuval
> Subject: Re: [PATCH v4] bnx2x: Alloc 4k fragment for each rx ring buffer
> element
>
> Yuval Mintz writes:
>
> > Regardless, I'll give it a more thorough review tomorrow.
> > [If those are all the "problems" we'll find with it, I don't thi
On 21.05.2015 15:20, Gabriel Krisman Bertazi wrote:
> Yuval Mintz writes:
>
>> Regardless, I'll give it a more thorough review tomorrow.
>> [If those are all the "problems" we'll find with it, I don't think we'll
>> need to re-spin this once more; that is, unless Dave insists]
>
> As a follow up
On 05/21/2015 03:20 PM, Gabriel Krisman Bertazi wrote:
> +#define SGE_PAGE_SHIFT 12
> +#define SGE_PAGE_SIZE(1 << SGE_PAGE_SHIFT)
...
> +struct bnx2x_alloc_pool {
> + struct page *page;
> + dma_addr_t dma;
> + u8 offset;
> + u8
>> +struct bnx2x_alloc_pool {
>> + struct page *page;
>> + dma_addr_t dma;
>> + u8 offset;
>> + u8 frag_count;
>> +};
>...
>> static int bnx2x_alloc_rx_sge(struct bnx2x *bp, struct bnx2x_fastpath *fp,
>> u16 index, gfp_
Yuval Mintz writes:
> Actually, this upsets me greatly. We didn't see it on a system with 4KB
> pages, but this means you've actually tried to 'sell' us a fastpath fix that
> was never tested on machines for which it was meant as an improvement.
The iteration that inserted this bug was such a qu
