> From: Sagi Grimberg [mailto:sagi@xxxxxxxxxxx] > 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 ��.n��������+%������w��{.n�����{���fk��ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
