Hi Herbert, Since netlink is being used for a lot of things now, it may be time to obsolete those assumptions. I'm not against changes. But so far I haven't seen anything concrete about what these ne
The idea is to reproduce the overun ;-> Probably debug prints slowing things; you could of course do some batching like so: $TC actions add \ action drop index 1 action drop index 2 action drop index
So lets start by using the following logic: 1) If you made the socket buffers small enough compared to message size/arrival rate, then an overrun will happen corrollary: 2) If you made the message si
There are three possible netlink usages: 1) Request/response: No overruns should occur. 2) Dump: No overruns should occur because of dump only fills in the next one when the previous one is taken off
Can someone please tell me why we need to do this at all? Most of the dump messages should be close to PAGE_SIZE anyway, no? -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~}
I see. NLMSG_GOODSIZE is definitely a waste in that case. I'd let the responder allocate that page skb as they do now. After all what we lack is space on the receive queue, not kernel memory. So long
This is the crux of the problem, you don't know how big the response will be until you look at the whole object you are returning. This is because there are usually an unknown number of attributes th
I understand. What I'm saying is that some of these places already know how big it is going to be. See tcp_diag.c for an example. So we shouldn't impose the copy over head on everyone. I agree comple
Here is a demonstration of what I meant. Please note that this is totally untested. We could just make the last argument of netlink_unicast into a flag so that it can do this directly. Cheers, -- Vis
Try harder! ;-> Ok, I will go and lookup my test machine and get back with an exact test case (problem is whenever i have time to scan my emails i am at least 30 minutes away from that box). cheers,
Cant assume this. A request for an ACK is fine. A get is a different ball game. I think the discussion to have a mini-slab-like allocator for netlink that i see going on in other thread is what we ne
20 bytes for the header; typical messages and attributes are in the range of 20 bytes. In the problematic case #2 or #3 (from what i have seen) in your previous email, you get events being broadcast
What I meant is that this is a case where the maximum size of the reply can be known at compile time. So assuming that your socket receive size is set correctly, it should never overflow. You still h
Sorry, keep forgetting to retrieve it from other remote non-networked test machine. The idea is: Create something that generates lots of messages. Make socket buffer small (4096 is good nuf) cheers,
No that's not what I meant. What I mean is what is the real-world scenario where you're going to be doing 3). Only when we know where the messages are coming from and what they are can we decide on a
The real world scenario is just that: Massive events generated from the kernel for example Ok, heres a sample testcase i created just now following those same instructions i gave you ;-> -- ifconfig
But ifconfig doesn't use netlink. So I presume you're referring to some other application that's listening for interface/address/route events. Firstly thanks this is exactly what I've been asking for