On Fri, Feb 26, 2016 at 11:43 AM, Sheng Yang <sheng@xxxxxxxxxx> wrote: > On Fri, Feb 26, 2016 at 11:38 AM, Andy Grover <agrover@xxxxxxxxxx> wrote: >> On 02/25/2016 06:03 PM, Sheng Yang wrote: >>>>>> >>>>>> -#define DATA_SIZE (257 * 4096) >>>>>> +#define DATA_SIZE (DATA_BLOCK_BITS * DATA_BLOCK_SIZE) >>>>> >>>>> >>>>> >>>>> So the reason this was 25*7* was because in testing I saw repeated >>>>> lengths >>>>> of size 512KiB, and due to the ring not being able to be completely used >>>>> (a >>>>> limitation of the circular buffer logic) this would result in only one >>>>> request and the second having to wait. Another page allowed 2 to fit at >>>>> once >>>>> :) so now that we're not using a ring any more this can probably just be >>>>> 256 >>>>> and still fit 2 512KiB allocations. >>>>> >>>> >>>> Sure. Would update. >>> >>> >>> In fact I just run another test again 256 * 4096, and found there are >>> many requests just 1MB long. So the following warning is triggered: >>> >>> "TCMU: Request of size 4160/1048576 may be too big for 65408/1048576 >>> cmd/data ring buffers." >>> >>> Probably we want to increase the buffer size a bit? >>> >>> But also it shows that we cannot accommodate all the upper layer >>> request in the buffer... There is no way we can allocate 1MB buffer >>> for each request. >> >> >> I thought we could allocate an exactly 1MB buffer, with your changes, no? >> That warning message may need to be changed. > > Yes we can, it make sense to remove the warning message. > > Though I am not quite comfortable with one request fill the whole > buffer, because we would only able to handle one request with the > whole ring. > > Like we discussed in > http://comments.gmane.org/gmane.linux.scsi.target.devel/11107 , we > should have a ring buffer fits all requests from upper layer. I think warning makes some sense because we should error out if request is bigger than our whole data ring. I would update the patch for that. We can decide what's to do with size of data ring later. --Sheng > > --Sheng > > >> >> -- Andy >> -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
