RE: nic enumeration

[Loke, Chetan]

> -----Original Message-----
> From: Steve Fink [mailto:sphink@xxxxxxxxx]
> Sent: July 09, 2010 5:27 PM
> To: Loke, Chetan
> Cc: Florian Weimer; linux-net@xxxxxxxxxxxxxxx; Matt Domsch; Michael Di
> Domenico; linux-kernel@xxxxxxxxxxxxxxx; kay.sievers@xxxxxxxx
> Subject: Re: nic enumeration
> 
> 
> Your problem is different from the one that began this thread. Can you
> describe your situation more fully?
> 

Sorry guys, I thought I mentioned my requirement. And I apologize for
pulling in my discussion in this thread.

Requirement:
I've a box with 'M' NICs. During install time, all the h/w config is
static, customers will configure the box. They would say use 'ethX' for
task-foo and 'ethY' for task-bar.
All this while our-apps where happy because we would never modify the
h/w config(single NIC vendor). So the configuration was pretty static.
However, we now let customers add/replace NICs from different vendors(so
different drivers will get loaded).The older 'ethX' might now map to a
newly-inserted-NICs-mac. So I would now like an 'ethX' agnostic way of
addressing the NICs and BTW we can't reboot the box[look below why].

Possible solution:
S1)I thought symlink[or a reference etc] would solve this problem. 
S2)I have another idea in mind(using mac-ids,enhance dev_ioctl[introduce
SIOCGHWADDR_TO_IFNAMEINDEXMAP] and traverse
for_each_netdev::for_each_dev_addrs) but I will wait for everyone's
suggestions because there might be an easy way.

Why can't I reboot?
Imagine the above configuration within a VM. Some customers have as many
as 75+ VMs deployed and we cannot afford to reboot the VMs after adding
a new (virtual)vNIC. The newly added vNIC is seen by the guest as if it
were a hot-insertion.


> I only partially understand your problem, but I am still wondering if
> my bridge idea would work for you. (Preferably combined with udev
> rules or whatever so the bridges are unnecessary after the next
> reboot.)

Why a bridge? Just to get around naming issues?

Regards
Chetan Loke
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/