> > On the other hand trying to hook offloaded iWARP into the normal stack > > does seem to lead to a mess. I see DaveM's point: TCP port space is > > just the beginning -- filtering, queueing, etc also have config that > > ultimately an offload device would want to hook too.
> TCP port space is just the beginning but then these features > didn't show up all at once in the kernel either. Instead of > evolving iWARP implementation, we can't even take a baby step > and fix a flaw that exists in the current kernel. Why are we > "replicating" everything offered by the host stack instead of > hooking in? It does not sound like good engineering to me. Well as I said I don't particularly see a clean solution. But the point I was making was that the net stack is already very complex with many places where interface configs are controlled -- having to add hooks to pass that config on to offload devices is going to add even more complexity and also add constraints to the format of that config information. Which is not good. - R. -- Roland Dreier <[email protected]> || For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
