[dm-devel] [PATCH V3 1/3] multipath-tools: Increase MAX_REPLY_LEN.

[Hannes Reinecke]

On 07/02/2016 02:25 AM, Gris Ge wrote:
> On Fri, Jul 01, 2016 at 04:46:53PM +0200, Hannes Reinecke wrote:
>>> -#define MAX_REPLY_LEN		65536
>>> +#define MAX_REPLY_LEN		10485760
>>> +/* ^ 10 MiB, enough for 'show maps json' command with 10k paths which
>>> + *   requires about 8 MiB */
>>>  
>>>  
>> Huh.
>> Can't say I like it. The limit is pretty much self-imposed, so I'd
>> rather bite the bullet and make it size-independent.
>>
>> Cheers,
>>
>> Hannes
>> -- 
>> Dr. Hannes Reinecke		   Teamlead Storage & Networking
> 
> Hi Hannes Reinecke,
> 
> How about limit the input command string size and let multipathd
> output size-independent?
> 
Hmm?
We already know the size of the input (we're getting it from the
commandline, after all). So there's no need to arbitrary limit anything
here; we know exactly how much memory we need to allocate.
It's just for the _output_ where we need to be careful, as we need to
ensure that we don't allocate insane amount of memory in the daemon nor
in the client.
So for the output we should look at implementing some sort of chunked
response; maybe having a 4k transmit buffer, and adding a status bit
in the CLI response instructing the client to keep on reading.
Or something like that.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		   Teamlead Storage & Networking
hare at suse.de			               +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x4EC8A8CF.asc
Type: application/pgp-keys
Size: 28230 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20160704/4df65c9f/attachment.bin>