RE: [PATCH] iscsi_iser: Re-enable 'iser_pi_guard' module parameter

Schremmer, Steven
2018-01-17T20:43:19Z

> From: Sagi Grimberg [mailto:sagi@grimberg.me]
> Sent: Wednesday, January 17, 2018 3:59 AM
> > Hannes,
> >
> >> Do we need to keep the parameter?
> >> If so we really should be re-enable it; ATM it's just a no-op leading
> >> the user to believe something has actually happened.
> >
> > The driver module parameters existed mainly for the purpose of hw
> > testing. One could disable IP checksum and revert to CRC to ensure both
> > code paths were working properly. But it wasn't really meant to be
> > something ordinary users would ever muck with. Why would anybody use the
> > much slower CRC when IP checksum was supported by the hardware? (*)
>
> Agree, but I definitely might not see the full picture here.
If the target uses CRC, the host will need a way to match.
AFAIK, there is no way in the SCSI protocol to determine this, so admin
has to set it up.

>
> > Anyway. I think Sagi's iser_pi_guard patch was a result of that
> > transition from driver global checksum setting to per-I/O ditto.
>
> Correct, and due to your comment above.
>
> > I don't have a problem with having a block-level preference knob
> > (slightly convoluted to implement since they are different integrity
> > profiles). But I do question whether it is worth the hassle. What
> > exactly is your use case that requires twiddling this?
A target that can do CRC Guard checks internally, but doesn't use IP
checksum.

>
> I'm not sure its worth it either, I can easily ack this one if that's
> the case.
This patch would restore the previous knob which meets the need
for now. If a better method is developed in the future, then great.

Thanks,
Steve