>
> > Good job tracking this down. Thanks!
> >
> > static void
> > iser_calc_scsi_params(struct iser_conn *iser_conn,
> > unsigned int max_sectors)
> > {
> > struct iser_device *device = iser_conn->ib_conn.device;
> > unsigned short sg_tablesize, sup_sg_tablesize;
> >
> > sg_tablesize = DIV_ROUND_UP(max_sectors * 512, SIZE_4K);
> > sup_sg_tablesize = min_t(unsigned, ISCSI_ISER_MAX_SG_TABLESIZE,
> > device->ib_device->attrs.max_fast_reg_page_list_len);
> >
> > iser_conn->scsi_sg_tablesize = min(sg_tablesize, sup_sg_tablesize);
> > }
> >
> > The bug is that device->ib_device->attrs.max_fast_reg_page_list_len
> should only be considered valid IFF IB_DEVICE_MEM_MGT_EXTENSIONS is
> set in
> > device->ib_device->device_cap_flags. The assignment you suggest should
> be an else on an if test of the device_cap_flags bit.
>
> Hi Guys,
>
> Good job tracking it down!
>
> I think you are the first one to test iSER on top of qib.
>
> Mike, What other variable do we need to look at to determine the
> maximum registered size per fmr? I was under the impression that
> max_fast_reg_page_list_len is not directly related to
> IB_DEVICE_MEM_MGT_EXTENSIONS as fmrs also accepts page lists.
>
I'm getting ready to send a patch.
For fmrs, there is no such indication available other than having the ULPs use trial fmr creation calls.
For qib, the only limit is memory to create the list embedded in the MR. For hfi1, the limit is UINT_MAX.
I suggest that we just handle the case of NOT seeing the bit by assuming ISCSI_ISER_MAX_SG_TABLE_SIZE.
An alternative is for non-extension drivers to assign this field as they see fit. Some other drivers seem to have limits that will fail creation.
max_fast_reg_page_list_len is poorly named though.
It seems simpler just to fix iser...
> Anyway,
> Can we please please please add proper support for wr based memory
> registrations in qib? I have a patch piped for removing FMRs from iser
> altogether, now that this came up I obviously can't send it...
>
This cannot be done without dropping support for older hardware.
qib variants (and perhaps other hardware) cannot deal with the receiving the send with invalidate packets.
> Looking at the code, looks like qib inherits rdmavt memory registration
> with the new api, the only missing piece afaict is the remote invalidate
> and qib can turn on IB_DEVICE_MEM_MGT_EXTENSIONS.
The code in the patch you suggested will never get executed because of the above hardware limitation. The hardware will queue an error and drop any data.
rdmavt reacts to control tables to handle the subordinate driver extension support correctly.
Mike
��.n��������+%������w��{.n�����{���fk��ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
