[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <B5657A6538887040AD3A81F1008BEC63DA8E49@avmb3.qlogic.org>
Date: Thu, 28 May 2015 07:24:22 +0000
From: Yuval Mintz <Yuval.Mintz@...gic.com>
To: Michal Schmidt <mschmidt@...hat.com>,
Gabriel Krisman Bertazi <krisman@...ux.vnet.ibm.com>
CC: David Miller <davem@...emloft.net>,
"LinoSanfilippo@....de" <LinoSanfilippo@....de>,
Ariel Elior <Ariel.Elior@...gic.com>,
netdev <netdev@...r.kernel.org>,
"cascardo@...cardo.eti.br" <cascardo@...cardo.eti.br>,
"brking@...ux.vnet.ibm.com" <brking@...ux.vnet.ibm.com>
Subject: RE: [PATCH v4] bnx2x: Alloc 4k fragment for each rx ring buffer
element
>> +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_t gfp_mask)
>> {
> ...
>> + pool->offset += SGE_PAGE_SIZE;
>> + pool->frag_count--;
>> +
>> return 0;
>> }
> One SGE_PAGE_SIZE is already bigger than representable by u8, so offset
> will overflow.
Thanks for the catch Michal.
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.
Dave - if possible, please wait with accepting any further fixes for this
issue until we [qlogic] manage to prepare a test environment
where we can properly test this with 64KB page size architecture.
Thanks,
Yuval--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists