Date: Thu, 17 Apr 2008 21:00:04 -0700 From: "Kip Macy" <kip.macy@gmail.com> To: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: MFC of TOE support to RELENG_7 Message-ID: <b1fa29170804172100v1adfbf59ta608984ee8a353cd@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
I would like to MFC TOE and RDMA support in the last week of May / first week of June. My primary objective is that it be present in 7.1. The re team has not yet decided when the freeze date for 7.1 will be, so I may end up asking to do it earlier. The reason I'm bringing it up roughly 6 weeks in advance is that there is a certain amount of debate with regards to the ABI guarantees that FreeBSD network developers are willing to commit to for the remaining life of the RELENG_7 branch. I've made the following two simplifying assumptions: - struct tcpcb and struct sockbuf are append only - i.e. if members are added, they will be added to the end - lock ordering will not change, e.g. the inpcb lock will always be acquired before the sockbuf lock Is there any reason to believe that these simplifying assumptions are not acceptable? If so, why? I've added the following sets of accessor functions: - lock acquire/release for socket, sockbuf, inpcb - higher level functions for tcp shutdown and syncache to abstract away the tcbinfo lock - accessor functions for all the accessed fields in socket and inpcb so that none of the members are referenced as offsets from the base of the structure There is an open question as to whether similar abstractions should be added to the various firewalls to allow them to be similarly decoupled to ease future maintenance. I would be willing to take a little time if someone stepped forward to explain the needs of the firewalls. I still need to do the following: - document the api provided by netinet/toedev.h - provide more formal documentation for the api provided by netinet/tcp_offload.h The current state of the code can be seen at: http://157.22.130.171/svn/branches/projects/iwarp/sys/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b1fa29170804172100v1adfbf59ta608984ee8a353cd>