On 20/10/2020 13:56, Jason Gunthorpe wrote:
On Tue, Oct 20, 2020 at 01:31:27PM +0100, Tvrtko Ursulin wrote:
On 20/10/2020 12:47, Jason Gunthorpe wrote:
On Tue, Oct 20, 2020 at 12:37:05PM +0100, Tvrtko Ursulin wrote:
Why put this confusing code in every caller? Especially for something
a driver is supposed to call. Will just make bugs
For max_segment to be aligned is a requirement today so callers are
ready.
No, it turns out all the RDMA drivers were became broken when they
converted to use the proper U32_MAX for their DMA max_segment size,
then they couldn't form SGLs anymore.
I don't want to see nonsense code like this:
dma_set_max_seg_size(dev->dev, min_t(unsigned int, U32_MAX & PAGE_MASK,
SCATTERLIST_MAX_SEGMENT));
In drivers.
dma_set_max_seg_size is the *hardware* capability, and mixing in
things like PAG_MASK here is just nonsense.
Code was obviously a no-op non-sense.
So the crux of the argument is that U32_MAX is conceptually the right thing
which defines the DMA max_segment size? Not some DMA define or anything, but
really U32_MAX? And that all/some DMA hardware does not think in pages but
really in bytes?
Yes.
The HW has 32 bits for a length field, so U32_MAX accurately defines
the HW DMA capability
Not just the max, but the granularity as well. If byte granularity (well
less than PAGE_SIZE/4k) exists in some hw then I agree the API change
makes sense.
Regards,
Tvrtko
