[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170512213404.rndcujbptjhhusww@lopatka.joja.cz>
Date: Fri, 12 May 2017 23:34:04 +0200
From: Jan Moskyto Matejka <mq@....cz>
To: David Miller <davem@...emloft.net>
Cc: mq@....cz, netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
dsa@...ulusnetworks.com, kuznet@....inr.ac.ru, jmorris@...ei.org,
yoshfuji@...ux-ipv6.org, kaber@...sh.net
Subject: Re: [PATCH] net: ipv6: Truncate single route when it doesn't fit
into dump buffer.
On Fri, May 12, 2017 at 11:24:47AM -0400, David Miller wrote:
> From: Jan Moskyto Matejka <mq@....cz>
> Date: Fri, 12 May 2017 13:15:10 +0200
>
> > -int rt6_dump_route(struct rt6_info *rt, void *p_arg);
> > +int rt6_dump_route(struct rt6_info *rt, void *p_arg, int truncate);
>
> Please use "bool" and "true"/"false" for boolean values.
Missed that, sorry. Will remember next time.
> What does ipv4 do in this situation?
>
> I'm hesitant to be OK with adding a new nlmsg flag just for this case
> if we solve this problem differently and using existing mechanisms
> elsewhere.
IPv4 is broken the same way as IPv6, with the difference that
'ip route append' does not append a new multipath nexthop but
creates a whole new route.
It is probably impossible to create such a big route via iproute2 tool;
it is needed to open netlink socket by hand and write there the
attached file. (It is one nlmsg adding one huge multipath route.)
It should be also noted that 'ip monitor' gets the huge routes
truncated.
MQ
Powered by blists - more mailing lists