Roland/All,
Here is the first swipe at keeping iwarp connections on their own ip

addresses to avoid conflicts with the host stack.
- this is a request for comments
- it is not yet tested fully (tested a prototype of the initial concept)
- still needs serialization/locking 
- stays in our RDMA sandbox ;-)
For background reading (if you dare), see:
http://www.mail-archive.com/general@lists.openfabrics.org/msg05162.html
and
http://www.mail-archive.com/netdev@vger.kernel.org/msg44312.html
Also: I'm on vacation starting tomorrow until Tuesday 9/4.  I'll address

comments when I return...
Steve.
---
iw_cxgb3: Support "iwarp-only" interfaces to avoid 4-tuple conflicts with

the host stack.
Design:
The sysadmin creates "for iwarp use only" alias interfaces of the form

"devname:iw*" where devname is the native interface name (eg eth0) for the

iwarp netdev device.  The alias label can be anything starting with "iw".

The "iw" immediately after the ':' is the key used by the iwarp driver.
EG:

	ifconfig eth0 192.168.70.123 up

	ifconfig eth0:iw1 192.168.71.123 up

	ifconfig eth0:iw2 192.168.72.123 up
In the above example, 192.168.70/24 is for TCP traffic, while

192.168.71/24 and 192.168.72/24 are for iWARP/RDMA use.
The rdma-only interface must be on its own subnet. This allows routing

all rdma traffic onto this interface.
The iWARP driver must translate all listens on address 0.0.0.0 to the

set of rdma-only ip addresses.  This prevents incoming connects to the

TCP ipaddresses from going up the rdma stack.
Implementation Details:
- The iwarp driver registers for inetaddr events via

register_inetaddr_notifier().  This allows tracking the iwarp-only

addresses/subnets as they get added and deleted.  The iwarp driver

maintains a list of the current iwarp-only addresses.
- The iwarp driver builds the list of iwarp-only addresses for its devices

at module insert time.  This is needed because the inetaddr notifier

callbacks don't "replay" address-a...
[ message continues ]

> The sysadmin creates "for iwarp use only" alias interfaces of the form

 > "devname:iw*" where devname is the native interface name (eg eth0) for the

 > iwarp netdev device.  The alias label can be anything starting with "iw".

 > The "iw" immediately after the ':' is the key used by the iwarp driver.
What's wrong with my suggestion of having the iwarp driver create an

"iwX" interface to go with the normal "ethX" interface?  It seems

simpler to me, and there's a somewhat similar precedent with how

mac80211 devices create both wlan0 and wmaster0 interfaces.
 - R.

-

It seemed much more painful for me to implement. :-)
I'll look into this, but I think for this to be done, the changes must

be in the cxgb3 driver, not the rdma driver, because the guts of the

netdev struct are all private to cxgb3.  Remember that this interface

needs to still do non TCP traffic (like ARP and UDP)...
Maybe you have something in mind here that I'm not thinking about?
Steve.
-

> > What's wrong with my suggestion of having the iwarp driver create an

 > > "iwX" interface to go with the normal "ethX" interface?  It seems

 > > simpler to me, and there's a somewhat similar precedent with how

 > > mac80211 devices create both wlan0 and wmaster0 interfaces.

 > >  - R.

 >

 > It seemed much more painful for me to implement. :-)

 >

 > I'll look into this, but I think for this to be done, the changes must

 > be in the cxgb3 driver, not the rdma driver, because the guts of the

 > netdev struct are all private to cxgb3.  Remember that this interface

 > needs to still do non TCP traffic (like ARP and UDP)...

 >

 > Maybe you have something in mind here that I'm not thinking about?
No, I was just spouting off.
But the whole "create a magic alias" seems kind of unfriendly to the

user.  Maybe as you said, the cxgb3 net driver could create the alias

for the iw_cxgb3 driver?
 - R.

-

I agree that it is not very user friendly.
My current patch just utilizes the IP address alias logic in the IP

stack.  So when you do 'ifconfig ethxx:blah ipaddr up' it creates a

struct in_ifaddr which contains a ptr to the real struct net_device that

services this alias.  However, from what I can tell, I cannot just

create one of these without binding an address.  So the driver cannot

create the alias interface until it knows the ipaddr/netmask/etc.  IE:

if you say 'ifconfig ethxx:blah up' it fails...  You must supply an

address to get one of these created.
To have the cxgb3 driver create something like 'iw0', I think it would

need to create a full net_device struct.  This makes the change much

more complex.  But perhaps its the right thing to do...
Steve.
-

Also, I could defer registering the device with the rdma core until the

alias interface is created by the user.  Thus the T3 device wouldn't be

available for use until the ethxx:iw interface is created.
And I could log a WARN or INFO message if the iw_cxgb3 module is loaded

and no ethxx:iw alias exists.  This would help clue in the user...
Steve.
-