> > > 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.
I don't want separate config file for L2 and iWARP as it adds more work and complexity for the user. I want it dead simple. I can see extending config format to include information specific for offload but I don't see how it can limit the format. That has not been the case up to this point. Also, port space patch is totally transparent to the user and config file. There is no managing host TCP and iWARP TCP port space for the user. I'm not sure about passing config info to offload devices, if the info is outside of what L2 driver currently picks up then sure some work needs to be done. Hopefully everything can be pass-through from L2 to iWARP. Chien -- 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
