On Sun, Oct 11, 2015 at 6:35 PM, Sagi Grimberg <sagig@xxxxxxxxxxxx> wrote: > By limiting the sg lists that we are allowing to meet > and 4k virtual boundary, we can completely remove the > entire bounce buffering logic. "limiting the sg lists that we are allowing to meet and 4k virtual boundary" This "and" must be typo, right? please fix. 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? and we are going to fix it with devices like mlx5 over the new API you're proposing, right? 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? If the 4X assertion made here is correct, 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? Or. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
