Hi Guys,
Having many ATM VCs, each having its own ethernet segment inside
I am exactly in the same situation as the VLAN guys.
(the kernel code for rfc2684/~1483/ bridged encapsulation is coming out
soon,
those who want an early look /perhaps audit/, please write to me)
My users want many interfaces, they want to ifconfig them, see counters,
set MAC addresses, they want whatever they do with their physical
ethernet interfaces. Several hundred interfaces per physical ATM card.
(still less than 409x VLANs though :)
I tried hard to follow Alexey's hints ("Think!").
I still do not know a better way than using the _existing_ tools (eg.
ifconfig)
for exactly what they were written for.
If a user chooses to have a longer list of interfaces than her terminal
can handle
;) I do not see a reason to restrict her.
Besides having a longer (but acceptable for 99%) creation and listing
time for interfaces
the only remarkable thing was /proc/sys/net/ipv4/conf.
(in our case only 145 entries were accessible, so we had to use the
conf/default directory
-ugly,eh?- before creating the devices and forget about changing those
values thereafter)
I do not talk for patching dev_alloc_name() , I used my own name
allocation
(like Werner's net/atm/clip.c).
I am just curious how I am supposed to 'split the level' and 'hide'
those interfaces
and still have the comfort of ifconfig and route, sorry, I mean ip.
All this with a reasonable amount of work and a maintainable set of
patches so
there migth be a slight chance of getting into 2.4
Actually some users create a large number of interfaces with the same
address and netmask, and have many route entries so that the kernel
chooses the right one (and the kernel handles it right and
efficiently; thx, Alexey). In this case it seems more reasonable to make
one interface and attach several ATM VCs to it and have a small
in-device routing (or we can call it perm-arp) to choose among the VCs.
However this raises proxy-arp issues;
(we have to proxy-arp because the segments in different VCs do not
otherwise see each other). This is possible to solve, but not in a nice
way.
(now that they are different interfaces the generic arp just solves
this...)
Sorry to stir this again, maybe I just want to hear that large number of
traditional interfaces is OK for now until we get back to this at 2.5
---- and now something completely different (not the larch)
- brdev->stats.tx_packets++;
- brdev->stats.tx_bytes += skb->len;
+ atomic_inc (&brdev->stats.tx_packets);
+ atomic_add (skb->len, &brdev->stats.tx_bytes)
I know that for SMP the atomic is
nicer but for statistics the simpler should do just fine (and I see the
simple
one more often in the kernel, but it might be just inheritance.)
For now I'll define dev_stats_inc() and dev_stats_add() macros so that
this decision
can be done later, but I am interested in the official policy.
Thank you,
Cell
|