"Christopher E. Brown" wrote:
>
> Think VLANing switch clusters. Say 4 switches connected by
> GigE on 4 floors or in 4 separate building. Now, across these
> switches 20 VLANS are running, with the switches enforcing VLAN
> partitioning. The client PCs know nothing about it, as each
On Sun, 7 Jan 2001, Alan Cox wrote:
> > Um, what about people running their box as just a VLAN router/firewall?
> > That seems to be one of the principle uses so far. Actually, in that case
> > both VLAN and IP traffic would come through, so it would be a tie if VLAN
> > came first, but
On Sun, 7 Jan 2001, Alan Cox wrote:
Um, what about people running their box as just a VLAN router/firewall?
That seems to be one of the principle uses so far. Actually, in that case
both VLAN and IP traffic would come through, so it would be a tie if VLAN
came first, but non-vlan
"Christopher E. Brown" wrote:
Think VLANing switch clusters. Say 4 switches connected by
GigE on 4 floors or in 4 separate building. Now, across these
switches 20 VLANS are running, with the switches enforcing VLAN
partitioning. The client PCs know nothing about it, as each one
On Mon, Jan 08, 2001 at 07:12:09PM +1300, Chris Wedgwood wrote:
> On Mon, Jan 08, 2001 at 06:32:14AM +0100, Andi Kleen wrote:
>
> I think it would be better to keep it. The ifa based alias
> interface emulation adds minor overhead (currently it's only a
> few lines of code, assuming
On Sun, Jan 07, 2001 at 04:01:04AM -0800, David S. Miller wrote:
>Date: Mon, 8 Jan 2001 01:13:08 +1300
>From: Chris Wedgwood <[EMAIL PROTECTED]>
>
>OK, I'm a liar -- bind does handle this. Cool.
>
> Standard BSD allows it, what do you expect :-)
>
>This is good news, because
Alan Cox wrote:
> > Um, what about people running their box as just a VLAN router/firewall?
> > That seems to be one of the principle uses so far. Actually, in that case
> > both VLAN and IP traffic would come through, so it would be a tie if VLAN
> > came first, but non-vlan traffic would
On Sun, 7 Jan 2001, Matti Aarnio wrote:
> On Sun, Jan 07, 2001 at 02:10:52PM -0500, jamal wrote:
> > OK. I suppose an skb->vlan_tag is passed to the driver and it will know
> > what to do with it (pass it on a descriptor etc).
>
> Sure, nice. WHY SHOULD THERE BE MORE LAYER-2 STUFF ADDED
On 7 Jan, Alan Cox wrote:
>> Um, what about people running their box as just a VLAN router/firewall?
>> That seems to be one of the principle uses so far. Actually, in that case
>> both VLAN and IP traffic would come through, so it would be a tie if VLAN
>> came first, but non-vlan traffic
On Sun, Jan 07, 2001 at 02:10:52PM -0500, jamal wrote:
> On Sun, 7 Jan 2001, Matti Aarnio wrote:
> > Read what I wrote about the issue to Alan.
> > Ben's code has no problems with receiving VLANs with network
> > cards which have "hardware support" for VLANs.
>
> OK. I suppose an
On Sun, 7 Jan 2001, Matti Aarnio wrote:
> Read what I wrote about the issue to Alan.
> Ben's code has no problems with receiving VLANs with network
> cards which have "hardware support" for VLANs.
>
OK. I suppose an skb->vlan_tag is passed to the driver and it will know
what
On Sun, Jan 07, 2001 at 01:21:11PM -0500, jamal wrote:
> On Sun, 7 Jan 2001, Ben Greear wrote:
> > > Question: How do devices with hardware vlan support fit into your model ?
> > I don't know of any, and I'm not sure how they would be supported.
>
> erm, this is a MUST. You MUST factor the
On Sun, 7 Jan 2001, Ben Greear wrote:
> jamal wrote:
> >
> > erm, this is a MUST. You MUST factor the hardware VLANs and be totaly
> > 802.1q compliant. Also of interest is 802.1P and D. We must have full
> > compliance, not some toy emulation.
>
> I have seen neither hardware nor spec sheets
On Sun, Jan 07, 2001 at 06:06:37PM +, Alan Cox wrote:
> > Um, what about people running their box as just a VLAN router/firewall?
> > That seems to be one of the principle uses so far. Actually, in that case
> > both VLAN and IP traffic would come through, so it would be a tie if VLAN
> >
jamal wrote:
>
> On Sun, 7 Jan 2001, Ben Greear wrote:
>
> > > Question: How do devices with hardware vlan support fit into your model ?
> >
> > I don't know of any, and I'm not sure how they would be supported.
> >
>
> erm, this is a MUST. You MUST factor the hardware VLANs and be totaly
>
> Thats what it already does, if I understand correctly. Of course, if VLAN
> is loaded as a module, then it will be in the hash before IP, right?
Thats fine. I think it'll be a different hash bucket anyway. The point of
having vlan first is that if its not registered or the interface isnt
Alan Cox wrote:
>
> > Um, what about people running their box as just a VLAN router/firewall?
> > That seems to be one of the principle uses so far. Actually, in that case
> > both VLAN and IP traffic would come through, so it would be a tie if VLAN
> > came first, but non-vlan traffic would
On Sun, 7 Jan 2001, Ben Greear wrote:
> > Question: How do devices with hardware vlan support fit into your model ?
>
> I don't know of any, and I'm not sure how they would be supported.
>
erm, this is a MUST. You MUST factor the hardware VLANs and be totaly
802.1q compliant. Also of interest
Alan Cox wrote:
>
> > Suppose I bind a raw socket to device vlan4001 (ie I have 4k in the list
> > before that one!!). Currently, that means a linear search on all devices,
> > right? In that extreme example, I would expect the hash to be very
> > useful.
>
> At this point you have to ask
> Um, what about people running their box as just a VLAN router/firewall?
> That seems to be one of the principle uses so far. Actually, in that case
> both VLAN and IP traffic would come through, so it would be a tie if VLAN
> came first, but non-vlan traffic would suffer worse.
Why would
Alan Cox wrote:
>
> > + * NOTE: That is no longer true with the addition of VLAN tags. Not
> > + * sure which should go first, but I bet it won't make much
> > + * difference if we are running VLANs. The good news is that
>
> It makes a lot of difference tha the
On Sun, Jan 07, 2001 at 11:56:26AM -0500, jamal wrote:
>
>
> On Sun, 7 Jan 2001, Chris Wedgwood wrote:
>
> > That said, if this was done -- how would things like routing daemons
> > and bind cope?
>
> I dont know of any routing daemons that are taking advantage of the
> alias interfaces
On Sun, Jan 07, 2001 at 04:46:14PM +, Alan Cox wrote:
> But talking between two vlans on the same physical lan you will go in and back
> out via the switch and you wont
So ?
If your box is routing in between VLANs, you are using it wrong way, IMO.
On the other hand, I could very well
> Ok. Good point.
> But remember that parsing /proc for an embedded system is also not the
> most healthy thing.
I dont compile in /proc either. SIOCGIFCONF is enough for an embedded box.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
> I just tried to pull data from another machine, which
> is on normal port thru VLAN trunking port to receiving
> machine, and got fast-ether at wire speed. (As near as
> ncftp's 11.11 MB/sec is wirespeed..)
But talking between two vlans on the same physical lan you will
In article <[EMAIL PROTECTED]>,
Alan Cox <[EMAIL PROTECTED]> wrote:
>At this point you have to ask 'why is vlan4001 an interface'. Would it not
>be cleaner to add the vlan id to the entries in the list of addresses per
>interface ?
Not all the world is IP - what if you want to bridge between
On Sun, Jan 07, 2001 at 10:56:23AM -0500, jamal wrote:
[snip]
>
> I used to be against VLANS being devices, i am withdrawing that comment; it's
> a lot easier to look on them as devices if you want to run IP on them. And
> in this case, it makes sense the possibilirt of over a thousand devices
On Sun, 7 Jan 2001, Alan Cox wrote:
> Why. Its bad enough that the networking layer doesnt let you configure out
> stuff like SACK and the big routing hashes. Please don't make it even worse
> for the embedded world. 99.9% of Linux boxes probably have less than 5 routing
> table entries
Ok.
On Sun, Jan 07, 2001 at 01:42:50PM +, Alan Cox wrote:
> > + * NOTE: That is no longer true with the addition of VLAN tags. Not
> > + * sure which should go first, but I bet it won't make much
> > + * difference if we are running VLANs. The good news is that
>
> Suppose I bind a raw socket to device vlan4001 (ie I have 4k in the list
> before that one!!). Currently, that means a linear search on all devices,
> right? In that extreme example, I would expect the hash to be very
> useful.
At this point you have to ask 'why is vlan4001 an interface'.
>thing so that some stupid program that depends on ifconfig look and feel
>would be a good start.
>
> I could not agree more. This reminds me to do something I could not
> justify before, making netlink be enabled in the kernel and
> non-configurable.
Why. Its bad enough that the
> + * NOTE: That is no longer true with the addition of VLAN tags. Not
> + * sure which should go first, but I bet it won't make much
> + * difference if we are running VLANs. The good news is that
It makes a lot of difference tha the vlan goes 2nd. Most sane
Date: Mon, 8 Jan 2001 01:13:08 +1300
From: Chris Wedgwood <[EMAIL PROTECTED]>
OK, I'm a liar -- bind does handle this. Cool.
Standard BSD allows it, what do you expect :-)
This is good news, because it means there is a precedent for multiple
addresses on a single interface so
Date:Sun, 7 Jan 2001 11:40:10 + (UTC)
From: "Henning P. Schmiedehausen" <[EMAIL PROTECTED]>
As long as "man ip" on my machines returns "ip(7) - ip - Linux IPv4
protocol implementation", using "ip" exclusively instead of
ifconfig and route is IMHO not an option for
[EMAIL PROTECTED] (David S. Miller) writes:
> Date: Sat, 6 Jan 2001 23:00:10 -0500 (EST)
> From: jamal <[EMAIL PROTECTED]>
> I think someone should just flush ifconfig down some toilet. a wrapper
> around "ip" to to give the same look and feel as ifconfig would be a good
> thing so
[EMAIL PROTECTED] (David S. Miller) writes:
Date: Sat, 6 Jan 2001 23:00:10 -0500 (EST)
From: jamal [EMAIL PROTECTED]
I think someone should just flush ifconfig down some toilet. a wrapper
around "ip" to to give the same look and feel as ifconfig would be a good
thing so that
Date:Sun, 7 Jan 2001 11:40:10 + (UTC)
From: "Henning P. Schmiedehausen" [EMAIL PROTECTED]
As long as "man ip" on my machines returns "ip(7) - ip - Linux IPv4
protocol implementation", using "ip" exclusively instead of
ifconfig and route is IMHO not an option for anyone
Date: Mon, 8 Jan 2001 01:13:08 +1300
From: Chris Wedgwood [EMAIL PROTECTED]
OK, I'm a liar -- bind does handle this. Cool.
Standard BSD allows it, what do you expect :-)
This is good news, because it means there is a precedent for multiple
addresses on a single interface so we
Suppose I bind a raw socket to device vlan4001 (ie I have 4k in the list
before that one!!). Currently, that means a linear search on all devices,
right? In that extreme example, I would expect the hash to be very
useful.
At this point you have to ask 'why is vlan4001 an interface'. Would
+ * NOTE: That is no longer true with the addition of VLAN tags. Not
+ * sure which should go first, but I bet it won't make much
+ * difference if we are running VLANs. The good news is that
It makes a lot of difference tha the vlan goes 2nd. Most sane people
thing so that some stupid program that depends on ifconfig look and feel
would be a good start.
I could not agree more. This reminds me to do something I could not
justify before, making netlink be enabled in the kernel and
non-configurable.
Why. Its bad enough that the networking
On Sun, Jan 07, 2001 at 01:42:50PM +, Alan Cox wrote:
+ * NOTE: That is no longer true with the addition of VLAN tags. Not
+ * sure which should go first, but I bet it won't make much
+ * difference if we are running VLANs. The good news is that
It
On Sun, 7 Jan 2001, Alan Cox wrote:
Why. Its bad enough that the networking layer doesnt let you configure out
stuff like SACK and the big routing hashes. Please don't make it even worse
for the embedded world. 99.9% of Linux boxes probably have less than 5 routing
table entries
Ok. Good
In article [EMAIL PROTECTED],
Alan Cox [EMAIL PROTECTED] wrote:
At this point you have to ask 'why is vlan4001 an interface'. Would it not
be cleaner to add the vlan id to the entries in the list of addresses per
interface ?
Not all the world is IP - what if you want to bridge between
an ATM
Ok. Good point.
But remember that parsing /proc for an embedded system is also not the
most healthy thing.
I dont compile in /proc either. SIOCGIFCONF is enough for an embedded box.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
On Sun, Jan 07, 2001 at 10:56:23AM -0500, jamal wrote:
[snip]
I used to be against VLANS being devices, i am withdrawing that comment; it's
a lot easier to look on them as devices if you want to run IP on them. And
in this case, it makes sense the possibilirt of over a thousand devices
is
I just tried to pull data from another machine, which
is on normal port thru VLAN trunking port to receiving
machine, and got fast-ether at wire speed. (As near as
ncftp's 11.11 MB/sec is wirespeed..)
But talking between two vlans on the same physical lan you will go
On Sun, Jan 07, 2001 at 11:56:26AM -0500, jamal wrote:
On Sun, 7 Jan 2001, Chris Wedgwood wrote:
That said, if this was done -- how would things like routing daemons
and bind cope?
I dont know of any routing daemons that are taking advantage of the
alias interfaces today. This
Alan Cox wrote:
Suppose I bind a raw socket to device vlan4001 (ie I have 4k in the list
before that one!!). Currently, that means a linear search on all devices,
right? In that extreme example, I would expect the hash to be very
useful.
At this point you have to ask 'why is
Alan Cox wrote:
+ * NOTE: That is no longer true with the addition of VLAN tags. Not
+ * sure which should go first, but I bet it won't make much
+ * difference if we are running VLANs. The good news is that
It makes a lot of difference tha the vlan goes
Um, what about people running their box as just a VLAN router/firewall?
That seems to be one of the principle uses so far. Actually, in that case
both VLAN and IP traffic would come through, so it would be a tie if VLAN
came first, but non-vlan traffic would suffer worse.
Why would someone
On Sun, 7 Jan 2001, Ben Greear wrote:
Question: How do devices with hardware vlan support fit into your model ?
I don't know of any, and I'm not sure how they would be supported.
erm, this is a MUST. You MUST factor the hardware VLANs and be totaly
802.1q compliant. Also of interest is
Alan Cox wrote:
Um, what about people running their box as just a VLAN router/firewall?
That seems to be one of the principle uses so far. Actually, in that case
both VLAN and IP traffic would come through, so it would be a tie if VLAN
came first, but non-vlan traffic would suffer
Thats what it already does, if I understand correctly. Of course, if VLAN
is loaded as a module, then it will be in the hash before IP, right?
Thats fine. I think it'll be a different hash bucket anyway. The point of
having vlan first is that if its not registered or the interface isnt doing
jamal wrote:
On Sun, 7 Jan 2001, Ben Greear wrote:
Question: How do devices with hardware vlan support fit into your model ?
I don't know of any, and I'm not sure how they would be supported.
erm, this is a MUST. You MUST factor the hardware VLANs and be totaly
802.1q compliant.
On Sun, Jan 07, 2001 at 04:46:14PM +, Alan Cox wrote:
But talking between two vlans on the same physical lan you will go in and back
out via the switch and you wont
So ?
If your box is routing in between VLANs, you are using it wrong way, IMO.
On the other hand, I could very well
On Sun, Jan 07, 2001 at 06:06:37PM +, Alan Cox wrote:
Um, what about people running their box as just a VLAN router/firewall?
That seems to be one of the principle uses so far. Actually, in that case
both VLAN and IP traffic would come through, so it would be a tie if VLAN
came
On Sun, Jan 07, 2001 at 01:21:11PM -0500, jamal wrote:
On Sun, 7 Jan 2001, Ben Greear wrote:
Question: How do devices with hardware vlan support fit into your model ?
I don't know of any, and I'm not sure how they would be supported.
erm, this is a MUST. You MUST factor the hardware
On Sun, 7 Jan 2001, Matti Aarnio wrote:
Read what I wrote about the issue to Alan.
Ben's code has no problems with receiving VLANs with network
cards which have "hardware support" for VLANs.
OK. I suppose an skb-vlan_tag is passed to the driver and it will know
what to
On Sun, Jan 07, 2001 at 02:10:52PM -0500, jamal wrote:
On Sun, 7 Jan 2001, Matti Aarnio wrote:
Read what I wrote about the issue to Alan.
Ben's code has no problems with receiving VLANs with network
cards which have "hardware support" for VLANs.
OK. I suppose an skb-vlan_tag
On Sun, 7 Jan 2001, Ben Greear wrote:
jamal wrote:
erm, this is a MUST. You MUST factor the hardware VLANs and be totaly
802.1q compliant. Also of interest is 802.1P and D. We must have full
compliance, not some toy emulation.
I have seen neither hardware nor spec sheets on how these
On 7 Jan, Alan Cox wrote:
Um, what about people running their box as just a VLAN router/firewall?
That seems to be one of the principle uses so far. Actually, in that case
both VLAN and IP traffic would come through, so it would be a tie if VLAN
came first, but non-vlan traffic would suffer
On Sun, 7 Jan 2001, Matti Aarnio wrote:
On Sun, Jan 07, 2001 at 02:10:52PM -0500, jamal wrote:
OK. I suppose an skb-vlan_tag is passed to the driver and it will know
what to do with it (pass it on a descriptor etc).
Sure, nice. WHY SHOULD THERE BE MORE LAYER-2 STUFF ADDED TO
Alan Cox wrote:
Um, what about people running their box as just a VLAN router/firewall?
That seems to be one of the principle uses so far. Actually, in that case
both VLAN and IP traffic would come through, so it would be a tie if VLAN
came first, but non-vlan traffic would suffer
On Sun, Jan 07, 2001 at 04:01:04AM -0800, David S. Miller wrote:
Date: Mon, 8 Jan 2001 01:13:08 +1300
From: Chris Wedgwood [EMAIL PROTECTED]
OK, I'm a liar -- bind does handle this. Cool.
Standard BSD allows it, what do you expect :-)
This is good news, because it means
On Mon, Jan 08, 2001 at 07:12:09PM +1300, Chris Wedgwood wrote:
On Mon, Jan 08, 2001 at 06:32:14AM +0100, Andi Kleen wrote:
I think it would be better to keep it. The ifa based alias
interface emulation adds minor overhead (currently it's only a
few lines of code, assuming we
On Sun, Jan 07, 2001 at 01:11:11AM -0700, Ben Greear wrote:
> > Packet socket binding or SO_BINDTODEVICE will search the list, but it is unlikely
> > that these paths are worth optimizing for.
>
> The patch has been written, so even if it helps just a little more than it
> hurts, it might be
Andi Kleen wrote:
> > I'm willing to run such benchmarks, but what would make a good benchmark,
> > other than ifconfig -a?
>
> ifconfig -a is fine IMHO. Everything else I know is just a single pass through
> the lists (which even at 4000 is not very significant)
Hardware: Celeron 500, mostly
On Sat, Jan 06, 2001 at 02:33:27PM -0700, Ben Greear wrote:
I'm hoping that I can get a few comments on this code. It was
added to (significantly) speed up things like 'ifconfig -a' when
running with 4000 or so VLAN devices. It should also help other
instances
Date: Sat, 06 Jan 2001 21:06:54 -0700
From: Ben Greear <[EMAIL PROTECTED]>
"David S. Miller" wrote:
>
> Unified diffs only please... Thanks.
Hrm, here's one with a -u option, this what you're looking for?
Yes, thanks a lot.
Later,
David S. Miller
[EMAIL PROTECTED]
-
To
On Sat, Jan 06, 2001 at 11:22:41PM -0700, Ben Greear wrote:
> At the time I was doing this, I downloaded the latest nettools version.
> The hashing made a very noticable difference on 4000 interfaces, but
> I haven't run any real solid benchmarkings at other levels. Can
> you tell me some
Andi Kleen wrote:
>
> On Sat, Jan 06, 2001 at 02:33:27PM -0700, Ben Greear wrote:
> > I'm hoping that I can get a few comments on this code. It was added
> > to (significantly) speed up things like 'ifconfig -a' when running with
> > 4000 or so VLAN devices. It should also help other instances
Chris Wedgwood wrote:
>
> On Sat, Jan 06, 2001 at 02:33:27PM -0700, Ben Greear wrote:
>
> I'm hoping that I can get a few comments on this code. It was
> added to (significantly) speed up things like 'ifconfig -a' when
> running with 4000 or so VLAN devices. It should also help
On Sat, Jan 06, 2001 at 11:00:10PM -0500, jamal wrote:
> Not to stray from the subject, Ben's effort is still needed. I think real
> numbers are useful instead of claims like it "displayed faster"
The problem with old ifconfig was really visible, old ifconfig needed several
minutes to setup. It
On Sat, Jan 06, 2001 at 02:33:27PM -0700, Ben Greear wrote:
> I'm hoping that I can get a few comments on this code. It was added
> to (significantly) speed up things like 'ifconfig -a' when running with
> 4000 or so VLAN devices. It should also help other instances with lots
> of (virtual)
"David S. Miller" wrote:
>
> Unified diffs only please... Thanks.
Hrm, here's one with a -u option, this what you're looking for?
--- ../../../linux/net/core/dev.c Mon Dec 11 14:29:35 2000
+++ dev.c Sat Jan 6 14:14:10 2001
@@ -1,4 +1,4 @@
-/*
+/* -*- linux-c -*-
* NET3
Unified diffs only please... Thanks.
Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
I'm hoping that I can get a few comments on this code. It was added
to (significantly) speed up things like 'ifconfig -a' when running with
4000 or so VLAN devices. It should also help other instances with lots
of (virtual) devices, like FrameRelay, ATM, and possibly virtual IP
interfaces. It
I'm hoping that I can get a few comments on this code. It was added
to (significantly) speed up things like 'ifconfig -a' when running with
4000 or so VLAN devices. It should also help other instances with lots
of (virtual) devices, like FrameRelay, ATM, and possibly virtual IP
interfaces. It
Unified diffs only please... Thanks.
Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
"David S. Miller" wrote:
Unified diffs only please... Thanks.
Hrm, here's one with a -u option, this what you're looking for?
--- ../../../linux/net/core/dev.c Mon Dec 11 14:29:35 2000
+++ dev.c Sat Jan 6 14:14:10 2001
@@ -1,4 +1,4 @@
-/*
+/* -*- linux-c -*-
* NET3
On Sat, Jan 06, 2001 at 02:33:27PM -0700, Ben Greear wrote:
I'm hoping that I can get a few comments on this code. It was added
to (significantly) speed up things like 'ifconfig -a' when running with
4000 or so VLAN devices. It should also help other instances with lots
of (virtual)
On Sat, Jan 06, 2001 at 11:00:10PM -0500, jamal wrote:
Not to stray from the subject, Ben's effort is still needed. I think real
numbers are useful instead of claims like it "displayed faster"
The problem with old ifconfig was really visible, old ifconfig needed several
minutes to setup. It
Chris Wedgwood wrote:
On Sat, Jan 06, 2001 at 02:33:27PM -0700, Ben Greear wrote:
I'm hoping that I can get a few comments on this code. It was
added to (significantly) speed up things like 'ifconfig -a' when
running with 4000 or so VLAN devices. It should also help other
Andi Kleen wrote:
On Sat, Jan 06, 2001 at 02:33:27PM -0700, Ben Greear wrote:
I'm hoping that I can get a few comments on this code. It was added
to (significantly) speed up things like 'ifconfig -a' when running with
4000 or so VLAN devices. It should also help other instances with
On Sat, Jan 06, 2001 at 11:22:41PM -0700, Ben Greear wrote:
At the time I was doing this, I downloaded the latest nettools version.
The hashing made a very noticable difference on 4000 interfaces, but
I haven't run any real solid benchmarkings at other levels. Can
you tell me some
Date: Sat, 06 Jan 2001 21:06:54 -0700
From: Ben Greear [EMAIL PROTECTED]
"David S. Miller" wrote:
Unified diffs only please... Thanks.
Hrm, here's one with a -u option, this what you're looking for?
Yes, thanks a lot.
Later,
David S. Miller
[EMAIL PROTECTED]
-
To
On Sat, Jan 06, 2001 at 02:33:27PM -0700, Ben Greear wrote:
I'm hoping that I can get a few comments on this code. It was
added to (significantly) speed up things like 'ifconfig -a' when
running with 4000 or so VLAN devices. It should also help other
instances
Andi Kleen wrote:
I'm willing to run such benchmarks, but what would make a good benchmark,
other than ifconfig -a?
ifconfig -a is fine IMHO. Everything else I know is just a single pass through
the lists (which even at 4000 is not very significant)
Hardware: Celeron 500, mostly idle
On Sun, Jan 07, 2001 at 01:11:11AM -0700, Ben Greear wrote:
Packet socket binding or SO_BINDTODEVICE will search the list, but it is unlikely
that these paths are worth optimizing for.
The patch has been written, so even if it helps just a little more than it
hurts, it might be worth
90 matches
Mail list logo
