On Wed, Nov 01, 2017 at 10:33:25AM -0700, Greg Rose wrote: > On 11/01/2017 09:38 AM, Ben Pfaff wrote: > >On Wed, Nov 01, 2017 at 08:28:48AM -0700, Greg Rose wrote: > >> On 10/31/2017 12:53 PM, Ben Pfaff wrote: > >>> On Fri, Sep 22, 2017 at 07:44:53AM -0700, Greg Rose wrote: > >>>> The maximum message size for recent Linux kernels is 32Kb and in older > >>>> kernels it is 16KB. > >>>> > >>>> See http://www.spinics.net/lists/netdev/msg431592.html > >>>> > >>>> Adjust the size checked and update a comment. > >>>> > >>>> Signed-off-by: Greg Rose <[email protected]> > >>> > >>> ... > >>> > >>>> diff --git a/lib/netlink.c b/lib/netlink.c > >>>> index de3ebcd..04310ff 100644 > >>>> --- a/lib/netlink.c > >>>> +++ b/lib/netlink.c > >>>> @@ -570,7 +570,7 @@ nl_msg_next(struct ofpbuf *buffer, struct ofpbuf > >>>> *msg) > >>>> bool > >>>> nl_attr_oversized(size_t payload_size) > >>>> { > >>>> - return payload_size > UINT16_MAX - NLA_HDRLEN; > >>>> + return payload_size > INT16_MAX - NLA_HDRLEN; > >>>> } > >>> > >>> Thanks for the patch! > >>> > >>> I am confused by a difference between the commit message and the code. > >>> Before this patch, nl_attr_oversized() considered an attribute of about > >>> 64 kB to be oversize; after this patch, about 32 kB. Shouldn't the new > >>> value be about 16 kB? > >>> > >>> Thanks, > >>> > >>> Ben. > >>> > >> > >> IIRC this is in user space so we prepare for whatever the maximum size we > >> might > >> get from a kernel, which is 32KB. > >> > >> We could have just left it at 64KB but we don't ever need that much. > > > >This response implies that nl_attr_oversized() has something to do with > >Netlink attributes for messages that userspace receives from the kernel. > >This is not the case. OVS userspace is prepared to handle any length > >attribute in Netlink messages that it receives. It won't apply > >nl_attr_oversized() to received attributes, it will just go ahead and > >process them. > > > >On the contrary, userspace uses nl_attr_oversized() to limit the maximum > >size of a Netlink attribute it *sends to* the kernel. If the kernel > >only supports a maximum 16 kB or 32 kB attribute, according to its > >version, then the function needs to apply this limit. The current code > >assumes that the kernel can process anything that can actually be > >formulated into Netlink. > > > >What actual limit does Linux apply to Netlink messages, for sending and > >receiving? I am beginning to believe that this function is a red > >herring and does not need to change. > > > So you're right, I didn't recall correctly... that's what I get for quick > answers. > > In net/netlink/af_netlink.c the core netlink handler will attempt to copy the > maximum length of the message and if it is not able to then it will set the > MSG_TRUNC flag and attempt to process whatever it can. The netlink > skb's are processed as datagrams. > > Generally the large size messages come from the kernel, not to the kernel > so it is not much of a concern for any applications I'm aware of. > > Does OVS send large messages to the kernel?
One example is when OVS sends a large number of actions as part of OVS_FLOW_CMD_NEW or OVS_FLOW_CMD_SET or OVS_PACKET_CMD_EXECUTE. OVS has a fallback for that, but it needs to know when to use it, that is, it needs to know how large is too large. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
