Hi Finn,
On Fri, Jun 07, 2019 at 11:02:36AM +1000, Finn Thain wrote:
> On Thu, 6 Jun 2019, Martin K. Petersen wrote:
>
> >
> > Ming,
> >
> > > Guenter reported scsi boot issue caused by commit c3288dd8c232 ("scsi:
> > > core: avoid pre-allocating big SGL for data").
> >
> > Applied to 5.3/scsi-queue, thank you!
> >
>
> Thanks, that seems to fix the esp_scsi regression.
>
> Am I right in thinking that commit c3288dd8c232 ("scsi: core: avoid
> pre-allocating big SGL for data") has the effect that any scsi host with
> sg_tablesize > 2 must now support chained sg lists?
Yeah, every driver should support chained SGL, in theory.
>
> In commit 4af14d113bcf ("[PATCH] scsi: remove the use_clustering flag"), I
> read that "setting the dma_boundary to PAGE_SIZE - 1 and the
> max_segment_size to PAGE_SIZE" is sufficient to inhibit clustering. Is
> that sufficient to inhibit chained sg lists for LLDs?
clustering just means that every segment(sg) can't cross page boundary, and
it is nothing to do with chained sg lists.
>
> Does it follow that #define SCSI_INLINE_SG_CNT 2 is now the upper bound
> for sg list entries (clamping sg_tablesize) for those LLDs (regardless
> support for chained sg lists)?
No, 2 just means that size of the pre-allocated SGL.
>
> Does commit c3288dd8c232 have similar implications for any LLD running on
> an architecture with CONFIG_ARCH_NO_SG_CHAIN=y?
As you saw in this patch, SCSI_INLINE_SG_CNT becomes 0 on any ARCH
with CONFIG_ARCH_NO_SG_CHAIN=y.
Thanks,
Ming
