Re: [PATCH v1 1/2] IB/iser: set block queue_virt_boundary

[Sagi Grimberg <sagig-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>]

> What happens now when an app wants to use 1K, 2K, 3K IOs? they can
> only use 1/4, 1/2 or 3/4 of the available memory for these
> transactions?

What? I'm not sure what you are talking about. what available memory?

> and we are going to fix it with devices like mlx5 over
> the new API you're proposing, right?

Fix what?

>
> If this is the case, aren't we introducing a regression for
> applications that used this IO pattern over devices which aren't
> capable as mlx5 is (e.g mlx4), in the sense that the required memory
> footprint to address the application IO demand can be made 4X bigger?

Regression? What makes you think that the memory footprint increases?
There is no additional memory introduced by setting the queue
virt_boundary.

It's simple, like NVME prps, the RDMA page vectors need to meet:
- first byte offset
- full pages of some page_size
- last page can end before page_size

Not every SG list meets the above. Up until now we used BB. Since the
block layer is perfectly capable of handling this for us, we can lose
this bounce buffering code.

The block layer will:
- refuse merges if bios are not aligned to the virtual boundary
- split bios/requests that are not aligned to the virtual boundary
- or, bounce buffer SG_IOs that are not aligned to the virtual boundary

There is no additional memory what-so-ever.

With our arbitrary SG list support, If our device supports it, we can
remove the virt_boundary so the block layer won't have to take care of
any of the above.

>
> If the 4X assertion made here is correct

Its not.

> why not keeping the current
> BB logic to come into play for such devices? I know that without the
> BB code our driver looks much nicer and elegant, but life is sometimes
> more complex... thoughts?

Now that the block layer can absolutely guarantee to pass SG lists that
meet our alignment requirements, I don't think we need the BB logic
anymore.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html