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@xxxxxxx +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)
Attachment:
0x4EC8A8CF.asc
Description: application/pgp-keys
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
