On 8/12/05, David S. Miller <[EMAIL PROTECTED]> wrote: > From: Dimitris Michailidis <[EMAIL PROTECTED]> > Date: Fri, 12 Aug 2005 10:00:12 -0700 > > > On 8/12/05, David S. Miller <[EMAIL PROTECTED]> wrote: > > > This would mean that every time we wish to change the data structures > > > and interfaces for TCP socket lookup, your drivers would need to > > > change. > > > > I think using TCP's own functions was done exactly to avoid this > > problem. > > That's doesn't achieve the desired result. > > I do plan to merge in IBM's move of the TCP hash tables over > to RCU style locking, and that will require knowledge of the > locking at the call sites to the functions you have exported > to the TOE drivers. The TOE drivers would break as a result.
TOE uses the same locking strategies the host TCP uses (lock_sock and the rest) so it should at least be familiar. It doesn't use ehash_lock or head->lock other than indirectly through functions such as the above, and does its normal lookups in its own lockless table that is based on flow ids rather than 4-tuples. I haven't seen the patches you mention recently, I recall seeing some RCU ehash discussion several months ago and that didn't seem it would have much of an impact. If you have something more recent I can take a look and tell you if it would affect anything. > > You are creating a maintainence headache for us as well. Once this > stuff gets exported to drivers, it becomes nearly impossible to > change. And I absolutely reserve the right to create restrictions of > use that increase the flexibility we have to change interfaces, data > structures, and locking strategies in the future. I think you have a fine attitude here. There are and there will be a lot more users of the SW TCP than of TOEs and I think you should feel free to improve the former however you can. The TOE code still works with kernels going back to 2.4.22, tracking changes in mainline TCP hasn't been an issue so far. If you can give maintainers a heads up before changes you think may be disruptive I think that would be plenty on your part. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
