> >> Christoph, > >> > >> This is a problem for mlx5 which exposes: > >> > >> props->max_fast_reg_page_list_len = (unsigned int)-1; > >> > >> Which is obviously wrong and needs to be corrected, but this is sort of > >> an overkill to allocate max supported unconditionally. > >> > >> How about choosing a sane default of 256/512 pages for now? I don't > >> think we'll see a lot of larger transfers in iser/nvmf (which actually > >> need MRs for iWARP). > >> > >> Alternatively we can allow the caller to limit the MR size? > > > > I'm fine with a limit in the core rdma r/w code. But why is this > > a problem for mlx5? If it offers unlimited MR sizes it should support > > that, or report a useful value. I don't see why fixing mlx5 should > > be a problem, and would rather see this driver bug fixed ASAP. > > Already sent out a fix for mlx5. But even then, if a driver offers huge > amount of translation entries per MR doesn't mean we need to allocate > gigantic MRs for imaginary transfer sizes... > > I'd be happier if this is controlled by the caller. Are there hard limits for iSER and NVMEF/RDMA? If so, then perhaps the caller should pass that in and the RDMA-RW will choose the min(passed_in_max, device_max)? -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
