Make LIST_FOR_EACH[_SAFE] variable take logically correct value upon loop termination.
Also, add regression tests for linked list routines, to ensure that this
change does not break code.
Also, add new macro LIST_FOR_EACH_REVERSE.
The Linux kernel returns ENOBUFS to userspace code to indicate that
a netlink message that the kernel wanted to send could not be due to
a lack of buffer space. We checked for this and dealt with it in
one recvmsg call but not in another. This change tolerates it in
both places.
Should fix a problem encountered on the OF6k under "hping3 --flood".
** This fix was done by Ben. **
Commit 0a9024a2d7, "Changes based on feedback from GigaFin," added support
for compiling on a system that lacked up-to-date Linux kernel headers, by
dropping support for a feature only in newer kernels on such a system.
But the code already supported such a system properly; only the lack of
a macro definition kept it from compiling. So define the macro ourselves
instead of disabling the feature.
To elaborate, there are two issues here.
The first is kernel support for NETLINK_ADD_MEMBERSHIP. Older
kernels don't support this. But NETLINK_ADD_MEMBERSHIP was added
at the same time as support for more than 32 netlink multicast
groups. Netlink multicast groups numbered less than 32 can be
subscribed using a different mechanism, and in fact we do that
for such groups. Thus, attempting to use NETLINK_ADD_MEMBERSHIP
on an older kernel basically can't happen, and if it did it would
be a bug in the OpenFlow kernel module for telling userspace to
subscribe to a multicast group that cannot exist on that kernel.
The second is the kernel headers that the userspace programs are
compiled with. Without the change quoted below, the userspace
programs will silently fail if they are compiled with 2.4.x
headers and then run on a 2.6.x kernel and given a multicast
group numbered above 32, because they will not even try to
subscribe to that group. With the change, the userspace programs
will work properly when run on 2.4.x or 2.6.x kernels regardless
of the multicast group number and regardless of whether the
headers they were compiled against were from 2.4.x or 2.6.x.
This has two notable omissions. First, only at most 4k of flow statistics
are reported. Second, aggregate statistics are not yet supported. Both
of these are fairly easily fixable, just not fixed yet.
We want to allow multiple OpenFlow connections to a switch, so that
dpctl and other management tools can also connect to a switch that
is connecte to the controller. These tools will want to fetch the
information in the data_hello message, but currently this can only
be done by sending a control_hello message, which changes the
switch configuration state. So breaking the hello messages up into
multiple different messages, only some of which affect configuration
state, cures the problem.
Also, clean up the kernel datapath a bit, by adding helper functions
for allocating and resizing Generic Netlink messages that encapsulate
OpenFlow messages.
This is needed in the userspace switch code also. That
change is implemented in later change "Send replies to
OpenFlow requests only to the sender". Really that part
of the change should be moved into this one, but intervening
changes are intertwined enough with the same code to
make that difficult.
Justin Pettit
Ben Pfaff
Ben Pfaff
root
Natasha Gude