On Tue, Jul 20, 2010 at 12:45:49AM -0400, Martin K. Petersen wrote: > >>>>> "Christof" == Christof Schmitt <christof.schmitt@xxxxxxxxxx> writes: > > Christof, > > Christof> The motivation stems from research how the integrity data can > Christof> be mapped to the hardware interface used by the zfcp > Christof> driver. When passing data segments to the zfcp hardware > Christof> controller, there is the constraint that each data segment has > Christof> a maximum size of 4k and a segment must not cross a 4k > Christof> boundary. > > Ok. > > > Christof> Right now, this is done by reporting the maximum segment size > Christof> and segment boundary accordingly from zfcp. When issuing a > Christof> request, zfcp simply walks the sg list and passes the segments > Christof> to the hardware controller, no mapping or readjustment is > Christof> necessary in the driver. > > In that case I don't really have a problem with adhering to the queue > segment size and segment boundary for the integrity metadata. As long > as we avoid using the max number of data segments to cap the integrity > scatterlist because that'll definitely break a lot of stuff. > > Does the zfcp hardware have scatterlist length constraints? Yes. There is a hardware limit for the maximum number of scatterlist entries the driver can send to the hardware at the same time. For adding integrity data, we have to come up with a way to map both, integrity data and user data in the same hardware request. This is the experimental zfcp integrity data patch i sent for upstream inclusion: http://marc.info/?l=linux-scsi&m=127928781200392&w=2 The approach is that the driver has to adhere to the hardware constraint of sum of all data segments (user plus integrity data). To have a simple approach that covers the case with one integrity data segment per user data segment, we only report half the size for the scatterlist length when running DIX. This guarantees that the other half can be used for integrity data. > >> Your change also has repercussions when merging requests and bios. > >> We'd need to honor the DI segmentation constraints when merging. > >> Otherwise we may end up going beyond the controller limits when > >> mapping the sgl. > > Christof> Meaning the integrity data sg list would have more entries > Christof> than max_segments? I have not seen this during my experiments, > Christof> but then i likely have not hit every case of a possible > Christof> request layout. > > It happens all the time. Ok, i have to look into that as well. It would be an issue with the approach we are looking at now: If there are max_segments data segments, and more than max_segments integrity data segments, we will overrun the hardware constraint. Christof -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
