On Thursday 27 April 2006 08:27, David S. Miller wrote:
> From: Andi Kleen <[EMAIL PROTECTED]>
> Date: Thu, 27 Apr 2006 08:17:35 +0200
>
> > On Thursday 27 April 2006 08:08, David S. Miller wrote:
> >
> > > I'm currently assuming that the protocol processing is still done in
> > > the kernel on b
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Thu, 27 Apr 2006 08:17:35 +0200
> On Thursday 27 April 2006 08:08, David S. Miller wrote:
>
> > I'm currently assuming that the protocol processing is still done in
> > the kernel on behalf of the user context, so the issues you raise
> > really aren't r
From: Kelly Daly <[EMAIL PROTECTED]>
Date: Thu, 27 Apr 2006 13:31:37 +1000
> It should be quite trivial to resize this pool using RCU.
Yes, a lot of this stuff can use RCU, in particular the channel
demux is a prime candidate.
There are some non-trivial issues wrt. synchronizing the net
channel
On Thursday 27 April 2006 08:08, David S. Miller wrote:
> I'm currently assuming that the protocol processing is still done in
> the kernel on behalf of the user context, so the issues you raise
> really aren't relevant.
>
> We really shouldn't be jumping the gun so far into the implementation
>
From: Rusty Russell <[EMAIL PROTECTED]>
Date: Thu, 27 Apr 2006 13:40:26 +1000
> We *used* to have an nf_cache mechanism to determine exactly when the
> netfilter hooks cared about a packet, but it was never used and was hard
> to reconcile with connection-tracking timeouts...
Let's not consider b
From: James Morris <[EMAIL PROTECTED]>
Date: Thu, 27 Apr 2006 00:58:41 -0400 (EDT)
> On Thu, 27 Apr 2006, Rusty Russell wrote:
>
> > netfilter (similarly raw sockets, bonding, divert). Or, we could delay
> > LOCAL_IN hook processing until we get to socket receive.
>
> This an idea proposed for
From: "Caitlin Bestler" <[EMAIL PROTECTED]>
Date: Wed, 26 Apr 2006 18:02:43 -0700
> Would it be reasonable to state that a net channel carrying
> SYNs should not be set up when the consumer is a user mode
> process?
I'm currently assuming that the protocol processing is still done in
the kernel o
Hi Andrew,
On Wed, Apr 26, 2006 at 03:07:33PM -0700, Andrew Morton told us:
> So there's something in -mm which fixes your kernel? It's usually the
> other way around ;)
actually this was the first time that I tried a "normal" kernel.
I haven't chosen to run -mm because it fixed something for m
On Thu, 27 Apr 2006, Rusty Russell wrote:
> netfilter (similarly raw sockets, bonding, divert). Or, we could delay
> LOCAL_IN hook processing until we get to socket receive.
This an idea proposed for skfilter [1], too, allowing packets to be
filtered by local endpoint.
[1] http://people.redha
Shaw wrote:
On 4/21/06, Andy Gospodarek <[EMAIL PROTECTED]> wrote:
On 4/21/06, Michael Chan <[EMAIL PROTECTED]> wrote:
On Fri, 2006-04-21 at 16:01 -0400, Andy Gospodarek wrote:
I just hate to see extra resources used to solve problems that good
coding can solve (not that my suggestion is nece
On Mon, Mar 20, 2006 at 02:37:04AM -0800, David S. Miller wrote:
> From: "Michael S. Tsirkin" <[EMAIL PROTECTED]>
> Date: Mon, 20 Mar 2006 12:22:34 +0200
>
> > Quoting r. David S. Miller <[EMAIL PROTECTED]>:
> > > The path an SKB can take is opaque and unknown until the very last
> > > moment it i
On Wed, 2006-04-26 at 12:30 -0700, Caitlin Bestler wrote:
> David S. Miller wrote:
>
> >
> > I personally think allowing sockets to trump firewall rules
> > is an acceptable relaxation of the rules in order to simplify
> > the implementation.
>
> I agree. I have never seen a set of netfilter ru
Hi Dave,
Thanks for your response. =)
On Wednesday 26 April 2006 17:59, you wrote:
> Ok I have comments already just glancing at the initial patch.
>
> With the 32-bit descriptors in the channel, you indeed end up
> with a fixed sized pool with a lot of hard-to-finesse sizing
> and lookup proble
Hi Rick,
thanks for your comments.
On Wed, Apr 26, 2006 at 03:26:17PM -0700, Rick Jones wrote:
>Robin Humble wrote:
>>attached is a small patch for e1000 that dynamically changes Interrupt
>>Throttle Rate for best performance - both latency and bandwidth.
>>it makes e1000 look really good on net
[EMAIL PROTECTED] wrote:
> From: "Caitlin Bestler" <[EMAIL PROTECTED]>
> Date: Wed, 26 Apr 2006 15:53:44 -0700
>
>> The netchannel qualifiers should only deal with TCP packets for
>> established connections. Listens would continue to be dealt with by
>> the existing stack logic, vj_channelizing on
Rick Jones wrote:
Christoph Hellwig wrote:
On Thu, Apr 13, 2006 at 07:59:21PM -0500, Larry Finger wrote:
I am planning on writing a new routine to be added to
net/ieee80211/ieee80211_geo.c that will populate an ieee80211_geo
object given a country code. The new routine will eliminate the need
On 4/21/06, Andy Gospodarek <[EMAIL PROTECTED]> wrote:
> On 4/21/06, Michael Chan <[EMAIL PROTECTED]> wrote:
> > On Fri, 2006-04-21 at 16:01 -0400, Andy Gospodarek wrote:
> >
> > > I just hate to see extra resources used to solve problems that good
> > > coding can solve (not that my suggestion is
>> Given that RFC2681 is Experimental (and I'm not aware of any current
>> efforts in the IETF to push it to the standard track), IHMO it would not
>> be inappropriate to make this behavior controlled via sysctl.
>
> I have to respectfully disagree.
OK, thanks for taking the time to look at it
From: "Caitlin Bestler" <[EMAIL PROTECTED]>
Date: Wed, 26 Apr 2006 15:53:44 -0700
> The netchannel qualifiers should only deal with TCP packets
> for established connections. Listens would continue to be
> dealt with by the existing stack logic, vj_channelizing
> only occurring when the the conne
David S. Miller wrote:
> From: Jeff Garzik <[EMAIL PROTECTED]>
> Date: Wed, 26 Apr 2006 15:46:58 -0400
>
>> Oh, there are plenty of examples of filtering within an established
>> connection: input rules. I've seen "drop all packets from
>> IPs" type rules frequently. Victims of DoS use those k
Hi,
I am using netem to add loss and then adding another qdisc within netem
according to the wiki. Then i want to change the netem drop probability
without having to delete the qdisc and recreate it. I try it but I get
invalid argument:
thorium-ini hedpe # tc qdisc add dev ath0 root handle
BTW, is the RFC 2681? I looked that one up on ietf.org and the RFC by
that number was a different beast entirely - at least at a very quick
glance.
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info a
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Wed, 26 Apr 2006 10:45:21 -0700
> +struct brifinfo {
> + __u8state;
> + __u32 cost;
> +};
> +
Maybe put the __u32 first and explicitly pad out the 3
bytes after the __u8? Just to be safe.
I know you use an assignment initializer, s
From: Jeff Garzik <[EMAIL PROTECTED]>
Date: Wed, 26 Apr 2006 15:46:58 -0400
> Oh, there are plenty of examples of filtering within an established
> connection: input rules. I've seen "drop all packets from IPs"
> type rules frequently. Victims of DoS use those kinds of rules to stop
> packet
From: "Caitlin Bestler" <[EMAIL PROTECTED]>
Date: Wed, 26 Apr 2006 13:20:50 -0700
> If you are dropping all packets from IP X, then how was the connection
> established? Obviously we are only dealing with connections that
> were established before the rule to drop all packets from IP X
> was creat
From: Rick Jones <[EMAIL PROTECTED]>
Date: Wed, 26 Apr 2006 15:16:18 -0700
> BTW, is the RFC 2681? I looked that one up on ietf.org and the RFC by
> that number was a different beast entirely - at least at a very quick
> glance.
Congestion window validation is the correct RFC.
-
To unsubscribe
On Wed, 26 Apr 2006 15:16:18 -0700
Rick Jones <[EMAIL PROTECTED]> wrote:
> > When you're bursty application is not sending, other flows can take up
> > the pipe space you are not using, and you must reprobe to figure that
> > out.
>
> If the "restarted" connection does normal slow-start, one of t
Stephen Hemminger <[EMAIL PROTECTED]> :
[...]
> --- /dev/null
> +++ bridge-2.6/net/bridge/br_netlink.c
[...]
> +static int br_fill_ifinfo(struct sk_buff *skb, const struct net_bridge_port
> *port,
> + u32 pid, u32 seq, int event, unsigned int flags)
> +{
[...]
> +nlmsg_failur
Robin Humble wrote:
[I sent this to the e1000-devel folks, and they suggested netdev might
have opinions too. the below text has changed a little bit to reflect
feedback from Auke Kok]
attached is a small patch for e1000 that dynamically changes Interrupt
Throttle Rate for best performance - b
The ixp2000 driver for the enp2611 was developed on a board with
three gigabit ports, but some enp2611 models only have two ports
(and only one onboard PM3386.) The current driver assumes there
are always three ports and so it doesn't work on the two-port
version of the board at all.
This patch a
When you're bursty application is not sending, other flows can take up
the pipe space you are not using, and you must reprobe to figure that
out.
If the "restarted" connection does normal slow-start, one of two things
will happen yes? Either it will grow its cwnd to >= the receiver's
window,
[I sent this to the e1000-devel folks, and they suggested netdev might
have opinions too. the below text has changed a little bit to reflect
feedback from Auke Kok]
attached is a small patch for e1000 that dynamically changes Interrupt
Throttle Rate for best performance - both latency and bandw
Sven Schuster <[EMAIL PROTECTED]> wrote:
>
> On Wed, Apr 26, 2006 at 02:36:18AM +0200, Nuri Jawad told us:
> > Did you create a high load on the system in the manner I described?
> > The bug once only appeared after about 6 hours here when line + CPU had
> > been mostly idle. But that was the long
From: John Heffner <[EMAIL PROTECTED]>
Date: Tue, 25 Apr 2006 10:27:37 -0400
> Yours is the first complaint of this kind I recall seeing, but I've
> expected for a while someone would have this type of problem. RFC2861
> seems conceptually nice at first, but there are a few things about it
> t
On Wednesday 26 April 2006 21:39, John W. Linville wrote:
> On Fri, Apr 21, 2006 at 10:52:10PM +0200, Jiri Benc wrote:
> > On Fri, 21 Apr 2006 22:52:08 +0200, Michael Buesch wrote:
> > > Can you please send your hacky patch for the bcm43xx
> > > to me, so I can come up with a clean one?
> >
> > Su
On Wed, Apr 26, 2006 at 02:36:18AM +0200, Nuri Jawad told us:
> Did you create a high load on the system in the manner I described?
> The bug once only appeared after about 6 hours here when line + CPU had
> been mostly idle. But that was the longest time between failures. Can you
> test with one
On Wed, Apr 26, 2006 at 06:37:34PM +0200, Jiri Benc wrote:
> On Wed, 26 Apr 2006 09:29:46 -0700 (PDT), Alex Davis wrote:
> > Here is an updated patch which addresses Randy's issues. I'm currently
> > running
> > this with no problems:
> > [...]
> > +module_param(ieee80211_regdom, int, 0666);
> >
I know y'all were wondering if I was ever going to merge wireless-dev
patches...I apologize for the delay. :-)
Please recall that I have collapsed the branching, and now all the
Devicescape-based stuff is on the master branch here:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wi
Jeff Garzik wrote:
> Caitlin Bestler wrote:
>> David S. Miller wrote:
>>
>>> I personally think allowing sockets to trump firewall rules is an
>>> acceptable relaxation of the rules in order to simplify the
>>> implementation.
>>
>> I agree. I have never seen a set of netfilter rules that would
Caitlin Bestler wrote:
David S. Miller wrote:
I personally think allowing sockets to trump firewall rules
is an acceptable relaxation of the rules in order to simplify
the implementation.
I agree. I have never seen a set of netfilter rules that
would block arbitrary packets *within* an estab
On Fri, Apr 21, 2006 at 10:52:10PM +0200, Jiri Benc wrote:
> On Fri, 21 Apr 2006 22:52:08 +0200, Michael Buesch wrote:
> > Can you please send your hacky patch for the bcm43xx
> > to me, so I can come up with a clean one?
>
> Sure, actually I planned to do it in a few minutes :-)
Hacky or not, I'
David S. Miller wrote:
>
> I personally think allowing sockets to trump firewall rules
> is an acceptable relaxation of the rules in order to simplify
> the implementation.
I agree. I have never seen a set of netfilter rules that
would block arbitrary packets *within* an established connection.
Jeff Garzik wrote:
>pull failed:
>[EMAIL PROTECTED] netdev-2.6]$ git pull
>git://lost.foo-projects.org/linux-2.6.git ixgb-upstream
>error: no such remote ref refs/heads/ixgb-upstream
>Fetch failure: git://lost.foo-projects.org/linux-2.6.git
Hmm, I apologize, I gave the wrong URL.
git://lost
From: "Caitlin Bestler" <[EMAIL PROTECTED]>
Date: Wed, 26 Apr 2006 09:57:22 -0700
> The major element I liked about Kelly's approach is that the ring
> is clearly designed to allow a NIC to place packets directly into
> a ring that is directly accessible by the user. Evolutionary steps
> are good,
On Mon, Apr 24, 2006 at 03:01:48PM +0200, Jiri Benc wrote:
> On Fri, 21 Apr 2006 19:44:31 -0700, Jouni Malinen wrote:
> > On Fri, Apr 21, 2006 at 10:53:28PM +0200, Jiri Benc wrote:
> > > Default management interface (wlanXap) confuses users. It is only needed
> > > for
> > > AP mode (and only unti
Added new section describing the sysfs interface.
Renumbered sections to be sequential (section 4 was AWOL).
Minor spelling corrections.
Signed-off-by: Mitch Williams <[EMAIL PROTECTED]>
diff -urpN linux-2.6.16.11-clean/Documentation/networking/bonding.txt
linux-2.6.16.11/Documentation/networkin
On Wed, Apr 26 2006, Ronciak, John wrote:
> Please follow what has been happening on netdev. Dave Miller added this
> BUG to 2.6.17-rc as something we (Intel LAD) pointed out to them. Jeff
> Garzik has, as of this morning, queued our e1000 patch for this. He's
> been a little behind.
Ah ok, I g
This is the start of adding support for rtnetlink to the bridge code.
So far it only supports accessing the list of links and notifying
about link changes. It is just a prototype to get early feedback, don't
use to build your own masterpiece yet.
--- bridge-2.6.orig/net/bridge/Makefile
+++ bridge-
On Wednesday 26 April 2006 09:44, Stephen Hemminger wrote:
> On Tue, 25 Apr 2006 17:06:25 -0700
>
> Guenther Thomsen <[EMAIL PROTECTED]> wrote:
[..]
> > Considering the recent NFS changes, I tried to get the system into
> > this state using just ttcp. With some determination, three more
> > hosts a
[EMAIL PROTECTED] wrote:
> Ok I have comments already just glancing at the initial patch.
>
> With the 32-bit descriptors in the channel, you indeed end up
> with a fixed sized pool with a lot of hard-to-finesse sizing
> and lookup problems to solve.
>
> So what I wanted to do was finesse the ent
[I hope this time it's OK - I'm sending from pine/Linux]
The following unlikely should be replaced by likely because the condition
happens every time unless there is a hard error to transmit a packet.
Signed-off-by: Hua Zhong <[EMAIL PROTECTED]>
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tc
On Tue, 25 Apr 2006 17:06:25 -0700
Guenther Thomsen <[EMAIL PROTECTED]> wrote:
> On Monday 17 April 2006 11:18, Stephen Hemminger wrote:
> > I don't know what you are doing different, but my 2 port SysKonnect
> > card is working fine. Running SMP AMD64 and 2.6.17 latest.
> >
> > Showing full spee
On Wed, 26 Apr 2006 09:29:46 -0700 (PDT), Alex Davis wrote:
> Here is an updated patch which addresses Randy's issues. I'm currently running
> this with no problems:
> [...]
> +module_param(ieee80211_regdom, int, 0666);
> MODULE_PARM_DESC(ieee80211_regdom, "IEEE 802.11 regulatory domain; 64=MKK");
--- "John W. Linville" <[EMAIL PROTECTED]> wrote:
> On Tue, Apr 25, 2006 at 02:04:50PM -0700, Alex Davis wrote:
> > Hello:
> >
> > I sent this patch earlier and got no response, so I'm sending it again.
> >
> >
> > I cloned
> > git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-
Please follow what has been happening on netdev. Dave Miller added this
BUG to 2.6.17-rc as something we (Intel LAD) pointed out to them. Jeff
Garzik has, as of this morning, queued our e1000 patch for this. He's
been a little behind.
If you want to know more about the problem, please read the
Hi,
My problematic e1000 card (that sporadically gets transmit timeouts with
a driver newer than 2.6.14) hits new problems in current git after this
commit:
[NET]: Add skb->truesize assertion checking.
I thought I'd mention it, since it may help fix the real problem.
Basically I get tons of:
John Que <[EMAIL PROTECTED]> wrote:
>
> I had spent time trying to write something which
> uses RTA_SRC and RTA_DST and got some problems.
> (I probably made something stupid.)
> I googled for such examples and did not get much.
> I saw that the zebra project and iproute uses
> netlinks but it is
Herbert Xu wrote:
On Mon, Apr 24, 2006 at 09:23:00AM +, Marco Berizzi wrote:
>
> What should I do? Mangling MSS with iptables --set-mss ?
> Altering MSS to 1440 did the trick. See:
> http://marc.theaimsgroup.com/?l=linux-netdev&m=114373067423528&w=2
--clamp-mss-to-pmtu should be the best o
Two machines, many configuration differences, I need to find which one
is causing this difference in behaviour:
Machine 1: (eth1 is on the correct 192.168.3.x network)
# ip neighbour add to 192.168.2.15 lladdr 00:0F:20:98:F8:86 nud \
reachable dev eth1
# cat /proc/net/arp
IP address
On Mon, Apr 24, 2006 at 09:23:00AM +, Marco Berizzi wrote:
>
> What should I do? Mangling MSS with iptables --set-mss ?
> Altering MSS to 1440 did the trick. See:
> http://marc.theaimsgroup.com/?l=linux-netdev&m=114373067423528&w=2
--clamp-mss-to-pmtu should be the best option.
Cheers,
--
On Mon, 2006-03-27 at 12:11 +1100, Michael Ellerman wrote:
> On Thu, 2006-03-02 at 13:40 -0600, Santiago Leon wrote:
> > From: Michael Ellerman <[EMAIL PROTECTED]>
> >
> > After a kexec the veth driver will fail when trying to register with the
> > Hypervisor because the previous kernel has not un
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
to receive the following updates:
MAINTAINERS |8 ++
drivers/net/e1000/e1000_main.c |1
drivers/net/forcedeth.c
Hello,
Does anybody knows where suh a code example
which gets routing info according to the destination IP using
GETROUTE netlink sockets
can be found ?
I had spent time trying to write something which
uses RTA_SRC and RTA_DST and got some problems.
(I probably made something stupid.)
I googled f
Jeff Kirsher wrote:
The following patches were diff's against Garzik's latest "upstream" branch and
can be pulled from the following location:
git://lost.foo-projects.org/linux-2.6.git ixgb-upstream
pull failed:
[EMAIL PROTECTED] netdev-2.6]$ git pull
git://lost.foo-projects.org/linux-2.6.
Stephen Hemminger wrote:
This is a workaround for the case edge-triggered irq's. Several users
seem to have broken configurations sharing edge-triggered irq's. To avoid
losing IRQ's, reshedule if more work arrives.
The changes to netdevice.h are to extract the part that puts device
back in list
John W. Linville wrote:
The following changes since commit 7c241d37fe0e6442c5cf3b5d73f7f58f2dc66352:
Michael Buesch:
bcm43xx: make PIO mode usable
are found in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
upstream
pulled
-
To un
John W. Linville wrote:
The following changes since commit 6b426e785cb81e53dc2fc4dcf997661472b470ef:
Linus Torvalds:
Merge git://git.kernel.org/.../kyle/parisc-2.6
are found in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
upstream-f
Kok, Auke wrote:
Hi,
This patch was already merged in Jeff Garzik's netdev upstream branch but
needs to go into 12.6.16.y and 2.6.17rc* as it fixes a critical buffersize
skb bug that is exposed by an earlier patch by Dave Miller and Herbert
Xiu. I'm therefore resending it:
Please apply to 2.6.1
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Mon, 24 Apr 2006 15:23:41 -0700
> This follows after the earlier two patches.
>
> Change the initialization of the class device portion of the net device
> to be done earlier, so that any races before registration completes are
> harmless. Add a
From: Hua Zhong <[EMAIL PROTECTED]>
Date: Mon, 24 Apr 2006 16:25:39 -0700
> Hi,
>
> I am developing a profiling tool to check if likely/unlikely usages are wise.
> I find that the following one is always a miss:
>
> # Hit# miss Function:[EMAIL PROTECTED]
> ! 0 50505 tcp_tr
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Tue, 25 Apr 2006 11:08:12 -0700
> Need to allow for VLAN header when bridging.
>
> Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
Applied, thanks Stephen.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a
Ok I have comments already just glancing at the initial patch.
With the 32-bit descriptors in the channel, you indeed end up
with a fixed sized pool with a lot of hard-to-finesse sizing
and lookup problems to solve.
So what I wanted to do was finesse the entire issue by simply
side-stepping it i
From: Kelly Daly <[EMAIL PROTECTED]>
Date: Wed, 26 Apr 2006 11:47:34 +
> Noting Dave's recent release of his implementation, we thought we'd
> better get this "out there" so we can do some early
> comparison/combining and come up with the best possible
> implementation.
Thanks for publishing
From: "Kok, Auke" <[EMAIL PROTECTED]>
Date: Tue, 25 Apr 2006 23:12:30 -0700
> This patch was already merged in Jeff Garzik's netdev upstream branch but
> needs to go into 12.6.16.y and 2.6.17rc* as it fixes a critical buffersize
> skb bug that is exposed by an earlier patch by Dave Miller and Herb
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Tue, 25 Apr 2006 15:16:35 -0700
> On Tue, 25 Apr 2006 14:46:49 -0700 (PDT)
> "David S. Miller" <[EMAIL PROTECTED]> wrote:
>
> > From: Stephen Hemminger <[EMAIL PROTECTED]>
> > Date: Tue, 25 Apr 2006 10:01:49 -0700
> >
> > > > # Hit# mis
Hi all,
Ive been trying to understand iptables kernel code and
basically how it functions. In doing so i have a few questions.
In the file ip_tables.c there is call do_replace() which
is used as the start point entry from sockopt.
That is this gets called
76 matches
Mail list logo
