OpenOnload 20101111-u1 Release Notes ==================================== These release notes describe the major new features, and known limitations and bugs. Please also see the Onload User Guide. ---------------------------------------- Multicast send bug ------------------ This release contains a bug relating to UDP multicast sends. In a very specific case Onload uses a different MAC address compared with the Linux kernel behaviour. If all of the following are true: - The application sends multicast UDP traffic to an accelerated interface. - The interface is chosen by the routing table. ie. The app has not use setsockopt(SOL_IP, IP_MULTICAST_IF). - The chosen route is the "default" route. - The chosen route is via a gateway. In this case Linux uses the appropriate multicast MAC address, whereas Onload uses the MAC of the gateway. ie. Onload does not handle the (ugly!) special case of the default route correctly. The workaround is to add a new route for multicast traffic into the route table as follows: ip route add 224.0.0.0/4 dev ethN ---------------------------------------- Epoll ----- Latest: We're still working on improving the epoll implementation. Keep watching this space. poll() is still likely to give superior performance in many cases, because the epoll interface requires locking in order to protect its internal state, which imposes extra overhead. Epoll acceleration can be disabled at runtime with EF_UL_EPOLL=0. In that case epoll continues to work, but is handled in the kernel, and the interrupt avoidance features of Onload are reduced. This is likely to be a win for apps that don't require spinning and have many sockets in the epoll set. We plan to do further work on epoll in the near future to address the limitations outlined below. Known limitations: - Files are removed from the epoll set when the file descriptor is closed, rather than when the last reference to the file goes away. - With EPOLLET and EPOLLONESHOT, the Onload implementation can return more than one event if mixing accelerated and non-accelerated paths on a socket. - Scalability when there are large numbers of sockets is relatively poor. - Deadlock is possible if a process fork()s concurrently with invoking epoll calls. ---------------------------------------- Lingering stacks ---------------- In one of our tests we see Onload stacks that persist for longer than expected after an application exits. The main downside of this is that a stack continues to consume resources until it is freed, and any sockets in the stack may not release reserved ports promptly. We are continuing to investigate. ---------------------------------------- Jumbo frames ------------ When using jumbo frames with TCP, Onload limits the maximum segment size to a little under 2K. It does this because the codebase does not yet support TCP segments that span more than one of Onload's fixed size packet buffers. In practice this should not present any problems unless the other end of the connection does not support negotiation of the MSS. ---------------------------------------- SLES9 ----- SLES9 is only supported with service pack 2 and later. On earlier SLES9 releases the Onload kernel driver does not build.