Hi David,
My intention when I wrote the second mail was just to provide some more
examples that further elaborate my first question. But as you noticed, I
couldnt resist the temptation to slip in a couple of new questions on
the new post :-(...sorry and will take your advice into consideration
On Mon, 2006-07-31 at 21:47 -0700, David Miller wrote:
> From: Rusty Russell <[EMAIL PROTECTED]>
> Date: Fri, 28 Jul 2006 15:54:04 +1000
>
> > (1) I am imagining some Grand Unified Flow Cache (Olsson trie?) that
> > holds (some subset of?) flows. A successful lookup immediately after
> > packet c
On Mon, Jul 31, 2006 at 03:00:28PM -0700, David Miller ([EMAIL PROTECTED])
wrote:
> From: Evgeniy Polyakov <[EMAIL PROTECTED]>
> Date: Mon, 31 Jul 2006 23:41:43 +0400
>
> > Since kevents are never generated by kernel, but only marked as ready,
> > length of the main queue performs as flow control
From: "Ma Lin" <[EMAIL PROTECTED]>
Date: Fri, 28 Jul 2006 18:37:15 +0800
> In FACK, the holes between SACK blocks are considered as loss. To a
> sender, when SACK comes in, loss_out would be non-zero. According to
> linux-2.6.17.7/net/ipv4/tcp_input.c, function tcp_time_to_recover(),
> this non-ze
On Tue, 01 Aug 2006 11:15:29 +1000
Philip Craig <[EMAIL PROTECTED]> wrote:
> Stephen Hemminger wrote:
> > On Mon, 31 Jul 2006 20:06:41 +1000
> > Philip Craig <[EMAIL PROTECTED]> wrote:
> >
> >> This patch implements transparent ethernet bridging for gre tunnels.
> >> There are a few outstanding i
From: Rusty Russell <[EMAIL PROTECTED]>
Date: Fri, 28 Jul 2006 15:54:04 +1000
> (1) I am imagining some Grand Unified Flow Cache (Olsson trie?) that
> holds (some subset of?) flows. A successful lookup immediately after
> packet comes off NIC gives destiny for packet: what route, (optionally)
> w
On Sun, Jul 30, 2006 at 02:54:56PM -0400, Kyle McMartin wrote:
> On Sun, Jul 30, 2006 at 11:35:32AM -0700, Andrew Morton wrote:
> > hm. A couple of those patches have been futzing around in -mm for over a
> > year and have been nacked by Jeff and are a regular source of grumpygrams.
> > I've been
David Miller <[EMAIL PROTECTED]> writes:
>> hdlc_fr: logical PVC devices have no headers (plain IPv4 etc. as seen
>> by tcpdump), but they append FR headers (4 or 10 bytes long) just
>> before passing the skb to physical device.
>
> If you hooked up fr_hard_header into dev->hard_header instead of
On Tue, 2006-01-08 at 11:30 +1000, Herbert Xu wrote:
>
> You can now disable the OOM killer on a per-process basis by
>
> echo -17 > /proc//oom_adj
>
nice to know ;-> At least you can protect some apps if you need to.
Only racoon and quagga are important for me.
But what happens then if you ha
On Mon, 2006-31-07 at 08:30 -0400, John W. Linville wrote:
> On Mon, Jul 31, 2006 at 10:15:40AM +0200, Christophe Devriese wrote:
>
> > If you bond 2 vlan subinterfaces, the patch is not necessary at all. In
> > that
> > case also the source device will be changed from eth0. to bond. So
> > tha
On Mon, Jul 31, 2006 at 09:24:27PM -0400, Jamal Hadi Salim wrote:
>
> In regards to reliability: The thing that really fscks people using
> daemons from what i have seen is the oom killer policies and the lack of
> correlation by apps. I just watched quagga die horribly on a 256M
> machine on fri
On Mon, 2006-31-07 at 17:49 -0700, Roland Dreier wrote:
> David> Why is this a relevant analogy? Well, you have physical
> David> hard-disks in your computer today, but at some point that
> David> device becomes largely superfluous. It makes more sense to
> David> have just a cpu
Stephen Hemminger wrote:
> On Mon, 31 Jul 2006 20:06:41 +1000
> Philip Craig <[EMAIL PROTECTED]> wrote:
>
>> This patch implements transparent ethernet bridging for gre tunnels.
>> There are a few outstanding issues.
>
> Why not use existing bridge code?
It does use the existing bridge code. Pe
From: Krzysztof Halasa <[EMAIL PROTECTED]>
Date: Tue, 01 Aug 2006 03:04:28 +0200
> hdlc_fr: logical PVC devices have no headers (plain IPv4 etc. as seen
> by tcpdump), but they append FR headers (4 or 10 bytes long) just
> before passing the skb to physical device.
If you hooked up fr_hard_header
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Fri, 28 Jul 2006 09:23:12 +0400
> I completely agree that existing kevent interface is not the best, so
> I'm opened for any suggestions.
> Should kevent creation/removing/modification be separated too?
I do not think so, object for these 3 operati
David Miller <[EMAIL PROTECTED]> writes:
> Krzysztof, which device driver exactly creates this problem
> in the first place?
I have a report (not sure but I think it's that) with hdlc_fr (Frame
Relay).
Grepping through the tree there might be problems with:
- net/8021q/vlan.c (probably not with
From: Zach Brown <[EMAIL PROTECTED]>
Date: Thu, 27 Jul 2006 12:18:42 -0700
[ I kept this thread around in my inbox because I wanted to give it
some deep thought, so sorry for replying to old bits... ]
> So as the kernel generates events in the ring it only produces an event
> if the ownership f
David> Why is this a relevant analogy? Well, you have physical
David> hard-disks in your computer today, but at some point that
David> device becomes largely superfluous. It makes more sense to
David> have just a cpu with a 10-gigabit ethernet interface
David> incorporated ont
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Tue, 1 Aug 2006 02:31:58 +0200
> Playing devil's advocate here: if the packets are processed on
> two different CPUs then this could also happen and break the test
> case.
>
> So the test is probably a bit fragile.
Good point.
> I generally agree it's
> If we process these in sequence in software interrupt, everything
> is fine. Processing of "A" will add the address, and the test
> ping packet "B" will respond properly.
>
> If you defer "A", everything breaks and the test packet "B" will
> get processed first and not work.
Playing devil's a
Hello Hugo,
Hugo Santos wrote:
> Hi,
>
>> On the other hand, if a ND daemon loose the synchronization, it is
>> unpredicable, I guess.
>
>What do you mean by synchronization in this context? My idea was to
> keep the ND state machine inside the kernel, and instead have the
> daemon be reac
> Ok, let's do it in the following way:
> I present new version of kevent with new syscalls and fixed issues mentioned
> before, while people look at it we can end up with mapped buffer design.
> Is it ok?
Yeah, that sounds good. I'm looking forward to seeing the next set of
patches :).
- z
-
T
From: Ralf Baechle <[EMAIL PROTECTED]>
Date: Fri, 30 Jun 2006 15:29:01 +0100
> Ages ago, changeset
>
> http://www.kernel.org/git/?p=linux/kernel/git/tglx/history.git;a=commit;h=22d864d542a0b92116751186f1794c7d0f1ca1b9
>
> which converted several protocols from using open coded comparisons to
> u
From: Brent Cook <[EMAIL PROTECTED]>
Date: Mon, 31 Jul 2006 17:16:48 -0500
> There has to be some thread that is responsible for reading
> events. Perhaps a reasonable thing for a blocked thread that cannot
> process events to do is to yield to one that can?
The reason one decentralizes event pro
On Monday 31 July 2006 17:00, David Miller wrote:
>
> So we'd have cases like this, assume we start with a full event
> queue:
>
> thread Athread B
>
> dequeue event
> aha, new connection
> accept()
> register new kevent
>
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Mon, 31 Jul 2006 23:41:43 +0400
> Since kevents are never generated by kernel, but only marked as ready,
> length of the main queue performs as flow control, so we can create a
> mapped buffer which will have space equal to the main queue length
> m
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Mon, 31 Jul 2006 23:36:29 +0200
> David Miller wrote:
> > Does this matter?
>
> I don't think it does. Its a huge corner case (unloading of the
> module which issued the QUEUE verdict while queueing the packet),
> and worst case is that we drop some
David Miller wrote:
> I noticed a subtle semantic change for nf_queue(). Previously, if we
> can't grab the module reference for the matching entry, we'd not free
> the skb, return 0, and the caller tries to iterate to the next hook.
>
> That behavior is preserved for singleton frames, but that's
This is a backport of the current 2.6.18 version of skge and sky2
drivers for use with older kernels. The drivers depend on the CRC32
module.
It has been compiled and tested on RHEL (2.4) and 2.6.8
but should work on other kernels past that point. It does depend on
ethtool_ops, if_vlan and mii s
So all of you userland control-plane fanatics, how will you handle
things like NFS root with these daemon-required variants of NDISC and
ARP?
I know the devils' advocate responses already, so don't bother with
responses saying things like 1) "do it in the initial ramdisk, we only
need the daemon
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Mon, 31 Jul 2006 20:36:58 +0200
> I'm going to do some more testing now ..
Thanks for all of this work Patrick.
I noticed a subtle semantic change for nf_queue(). Previously, if we
can't grab the module reference for the matching entry, we'd not f
From: Dave Jones <[EMAIL PROTECTED]>
Date: Mon, 31 Jul 2006 16:50:04 -0400
> 2.6.18rc2-gitSomething on my firewall box just triggered this..
Lockdep is perhaps confused.
> [515613.904945] swapper/0 is trying to acquire lock:
> [515613.931489] (&tbl->lock){-+-+}, at: [] neigh_lookup+0x50/0xaf
>
On Monday 31 July 2006 13:31, John W. Linville wrote:
> As usual I'll depend on Jiri to merge d80211 stack patches, then
> send me a pull request. If I apply your "Switch drivers to d80211"
> series now, that will undoutedly cause a breakage when Jiri asks me
> to pull this later.
>
Yeah, there ne
2.6.18rc2-gitSomething on my firewall box just triggered this..
Dave
[515613.791771] ===
[515613.841467] [ INFO: possible circular locking dependency detected ]
[515613.873284]
On Thu, Jul 27, 2006 at 12:37:14AM -0700, Michael Wu wrote:
> Alright, I've replaced all + lines with spaces with tabs.
>
> I also fixed one long line. The rest of them are nearly impossible to shorten
> well. The "(fc & IEEE80211_FCTL_FTYPE) == IEEE80211_FTYPE_DATA" style is
> really killing us
From: Krzysztof Halasa <[EMAIL PROTECTED]>
Date: Mon, 31 Jul 2006 22:04:33 +0200
> This is non-trivial because hard_header and hard_start_xmit
> functions currently can't return new skb address (hard_header()
> can't use skb_realloc_headroom() at all, xmit() can't use it if
> there is a need to re
From: Krzysztof Halasa <[EMAIL PROTECTED]>
Date: Mon, 31 Jul 2006 22:04:33 +0200
> Alexey Kuznetsov <[EMAIL PROTECTED]> writes:
>
> > All the rest of places just check, that there is enough space
> > for their immediate needs. If dev->hard_header() is NULL, it means that
> > stack does not need a
Hi Francois,
Thanks for your feedback, I have a few questions.
> > +return serviced;
> > +}
> > +
> > +/* Autodetects and initialises external phy for SMSC9115 and SMSC9117
flavors.
> > + * If something goes wrong, returns -ENODEV to revert back to
internal phy. */
> > +static int s
From: Oumer Teyeb <[EMAIL PROTECTED]>
Date: Mon, 31 Jul 2006 19:49:28 +0200
> it would be so great if some of you could spare a few minutes and take a
> look at the traces I provided.see below for the original postng...
If people are too backlogged and busy to reply to your original
posting,
From: Thomas Graf <[EMAIL PROTECTED]>
Date: Mon, 31 Jul 2006 17:41:42 +0200
> * Herbert Xu <[EMAIL PROTECTED]> 2006-08-01 00:01
> > Actually, if we're adding policy routing, we should seriously consider
> > whether living without a routing cache is still viable or not because
> > the cost of a rou
On Mon, Jul 31, 2006 at 04:01:43PM -0400, Jeff Garzik wrote:
> John W. Linville wrote:
> >Jeff, if a 10ms maximum delay is still acceptable to you, then please
> >pull from the bcm43xx branch of wireless-2.6 into the upstream branch
> >of netdev-2.6.
>
> Just to be clear, 'upstream' not 'upstream-
* Patrick McHardy <[EMAIL PROTECTED]> 2006-07-31 20:01
> Thomas Graf wrote:
> > * Ville Nuorvala <[EMAIL PROTECTED]> 2006-07-31 17:46
> >
> >>Shouldn't all these (struct fib_rule_hdr included) actually be defined
> >>in include/linux/rtnetlink.h?
> >
> >
> > We used to stuff everything into rtnet
John W. Linville wrote:
Jeff, if a 10ms maximum delay is still acceptable to you, then please
pull from the bcm43xx branch of wireless-2.6 into the upstream branch
of netdev-2.6.
Just to be clear, 'upstream' not 'upstream-fixes', correct?
P.S. FWIW, I'm still not totally happy w/ the (potent
On Mon, Jul 31, 2006 at 02:33:22PM +0400, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
> Ok, let's do it in the following way:
> I present new version of kevent with new syscalls and fixed issues mentioned
> before, while people look at it we can end up with mapped buffer design.
> Is it ok?
Since
On Thu, Jul 27, 2006 at 08:37:53PM -0400, John W. Linville wrote:
> As most of us are painfully aware, there is a blockage in getting
> bcm43xx patches upstream.(*)
> (*) http://marc.theaimsgroup.com/?l=linux-netdev&m=115137403631920&w=2
After re-reading that thread, I realized that Jeff had indi
This patch will correct the mac address and set a flag to indicate that
it is already corrected in case nv_probe is called again. For example,
when you use kexec to restart the kernel.
Signed-Off-By: Ayaz Abdulla <[EMAIL PROTECTED]>
--- orig-2.6/drivers/net/forcedeth.c2006-07-06 15:06:27.0
This patch moves the mac address setup/teardown to the
nv_probe/nv_remove functions. This fixes WOL wakeup since on nv_close we
would reverse the mac address. Also, bonding driver will reset address
after nv_close is called.
Signed-Off-By: Ayaz Abdulla <[EMAIL PROTECTED]>
--- orig-2.6/drivers
Thomas Graf wrote:
> * Ville Nuorvala <[EMAIL PROTECTED]> 2006-07-31 17:46
>
>>Shouldn't all these (struct fib_rule_hdr included) actually be defined
>>in include/linux/rtnetlink.h?
>
>
> We used to stuff everything into rtnetlink.h for no good reason. Having
> independant include/linux/.h to exp
Hi,
it would be so great if some of you could spare a few minutes and take a
look at the traces I provided.see below for the original postng...I
just had a couple of things to add which I noticed in linux TCP
behaviour which I have not seen documented anywhere else (or which I
might have
We've recently seen a number of user bug reports against e1000 that the
in-kernel irqbalance code is detrimental to network latency. The algorithm
keeps swapping irq's for NICs from cpu to cpu causing extremely high network
latency (>1000ms). Another NIC driver (cxgb) already has severe warnin
On Monday 31 July 2006 14:30, you wrote:
> (This is not directed at Christophe, or anyone in particular...)
>
>
>
> Am I the only one that thinks that our handling of LAN L2 stuff
> is at best a little "too" flexible (and at worst a collection of
> nasty hacks)?
>
> I mean, do we really need both
Randy.Dunlap wrote:
On Tue, 25 Jul 2006 09:20:06 -0700 Auke Kok wrote:
Alan Stern wrote:
During a Power Management session at the Ottawa Linux Symposium, it was
generally agreed that network interface drivers ought to automatically
suspend their devices (if possible) whenever:
(1) The int
On Tue, 25 Jul 2006 11:59:52 -0400 (EDT)
Alan Stern <[EMAIL PROTECTED]> wrote:
> During a Power Management session at the Ottawa Linux Symposium, it was
> generally agreed that network interface drivers ought to automatically
> suspend their devices (if possible) whenever:
>
> (1) The interfa
On Mon, 31 Jul 2006 20:06:41 +1000
Philip Craig <[EMAIL PROTECTED]> wrote:
> This patch implements transparent ethernet bridging for gre tunnels.
> There are a few outstanding issues.
Why not use existing bridge code?
> There is no way for userspace to select the type of gre tunnel. The
> #if 0
Hello Auke,
> > CONFIG_IRQBALANCE=y
thanks for the feedback. The behaviour improoved. In my first tests it
wasn't so good. But now it seems perfect:
(thinkpad) [~] ping 131.188.30.102
PING 131.188.30.102 (131.188.30.102) 56(84) bytes of data.
64 bytes from 131.188.30.102: icmp_seq=1 ttl=64 time=
On Mon, Jul 31, 2006 at 12:27:19AM -0400, David Coulson wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I have a machine running 2.6.18-rc3 with a bridge config that looks like
> this:
>
> cr1:~# brctl show
> bridge name bridge id STP enabled interfaces
> vlan10
* Herbert Xu <[EMAIL PROTECTED]> 2006-08-01 00:01
> Without a route cache, I think our only choice is to search through
> all tables. The same thing applies to PMTU updates as well.
I think PMTU etc. should be moved out of the route into a
some form of flow cache. It's currently using rt6_lookup(
Hello!
> It does seem weird that IP output won't pay attention to
Not so weird, actually.
The logic was:
Only initial skb allocation tries to reserve all the space
to avoid copies in the future.
All the rest of places just check, that there is enough space
for their immediate needs. If dev->ha
* Ville Nuorvala <[EMAIL PROTECTED]> 2006-07-31 16:55
> > When locating routes for redirects only the main table is
> > searched for now. Since policy rules will not be reversible
> > it is unclear whether it makes sense to change this.
>
> This is a good point. You are absolutely correct about th
* Ville Nuorvala <[EMAIL PROTECTED]> 2006-07-31 17:46
> > Derived from net/ipv6/fib_rules.c
>
> do you mean net/ipv4/fib_rules.c or net/ipv6/fib6_rules.c? :-)
Hehe, I meant net/ipv4/fib_rules.c :-)
> > +struct fib_rule_hdr
> > +{
> > + __u8family;
> > + __u8dst_len;
>
Thomas Glanzmann wrote:
Hello,
[ resend because .config and the used kernel version was missing ]
Linux Kernel Version: Linus Vanilla Tree; .config attached.
I recently aquired a Lenovo (IBM) T60 with a e1000 network card. I
experience high latency with this networkcard: Pings last upto 1 s
Thomas Graf wrote:
> Adds support for policy routing rules including a new
> local table for routes with a local destination.
Looks good!
> Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Signed-off-by: Ville Nuorvala <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscrib
Thomas Graf wrote:
Hi Thomas,
> Derived from net/ipv6/fib_rules.c
do you mean net/ipv4/fib_rules.c or net/ipv6/fib6_rules.c? :-)
A couple of comments below.
> Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
>
> Index: net-2.6.git/include/linux/fib_rules.h
> ===
On 28-07-2006 16:39, Jarek Poplawski wrote:
...
It has some great patch to queue scheduler by Hubert Xu. I think it is
I'm immensly sorry to change the name of Mr Herbert Xu.
And I thought it's easy name - just like some famous conductor
(but not so famous). You'll not believe, but when I wr
On Monday 31 July 2006 8:43 am, Venkat Yekkirala wrote:
> > The NetLabel patch allows administrators to assign specific a CIPSO
> > DOI/configuration to each LSM "domain". Blindly using the
> > CIPSO tag that the
> > remote host sends could violate the administrator's NetLabel
> > configuration.
>
On Tue, Aug 01, 2006 at 12:01:03AM +1000, Herbert Xu wrote:
> Ville Nuorvala <[EMAIL PROTECTED]> wrote:
> >
> >> When locating routes for redirects only the main table is
> >> searched for now. Since policy rules will not be reversible
> >> it is unclear whether it makes sense to change this.
> >
Ville Nuorvala <[EMAIL PROTECTED]> wrote:
>
>> When locating routes for redirects only the main table is
>> searched for now. Since policy rules will not be reversible
>> it is unclear whether it makes sense to change this.
>
> This is a good point. You are absolutely correct about the policy rul
Thomas Graf wrote:
> Adds the framework to support multiple IPv6 routing tables.
> Currently all automatically generated routes are put into the
> same table. This could be changed at a later point after
> considering the produced locking overhead.
Hi Thomes, some minor comments below.
> When lo
> The NetLabel patch allows administrators to assign specific a CIPSO
> DOI/configuration to each LSM "domain". Blindly using the
> CIPSO tag that the
> remote host sends could violate the administrator's NetLabel
> configuration.
>
> The current patch reads the CIPSO tag off the child sock
On Mon, Jul 31, 2006 at 10:15:40AM +0200, Christophe Devriese wrote:
> If you bond 2 vlan subinterfaces, the patch is not necessary at all. In that
> case also the source device will be changed from eth0. to bond. So
> that's correct behavior no ?
>
> In the second case, you create vlan subifs
From: Wei Yongjun <[EMAIL PROTECTED]>
Date: Mon, 31 Jul 2006 06:33:42 -0400
> In udp_queue_rcv_skb(), checksum condition is error. When UDP filter is
> set, checksum is be done, but if UDP filter is not set, checksum will
> not be done. So I think this is a BUG.
It is not a bug, we defer the chec
Wei Yongjun <[EMAIL PROTECTED]> wrote:
> In udp_queue_rcv_skb(), checksum condition is error. When UDP filter is
> set, checksum is be done, but if UDP filter is not set, checksum will
> not be done. So I think this is a BUG. Following is my patch:
>
> --- a/net/ipv4/udp.c2006-07-31 09:33:45.3
On Mon, Jul 31, 2006 at 12:39:51PM +0200, Patrick McHardy wrote:
>
> These are the patches (some variantions tested, but not all) on
> top of Herbert's CHECKSUM_PARTIAL patch. The first one fixes up
> the CHECKSUM_PARTIAL patch for 2.6.18-rc3, the second one fixes
> checksumming in all of netfilte
On Mon, Jul 31, 2006 at 03:57:16AM -0700, David Miller wrote:
>
> So I would say for up to 4 or 5 events, system call overhead alone
> touches as many cache lines as the events themselves.
Absolutely.
The other to consider is that events don't come from the hardware.
Events are written by the ke
David Miller wrote:
> From: Thomas Graf <[EMAIL PROTECTED]>
> Date: Thu, 27 Jul 2006 00:00:01 +0200
>
>> (Ab)using rt6_lock wouldn't work anymore if rt6_lock is
>> converted into a per table lock.
>>
>> Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
>
> This one looks great.
>
> Signed-off-by: D
Thomas Graf wrote:
> Hello,
Hi Thomas!
> Thought it might be time to go through a round of comments
> on this work. Even though I've almost rewritten all the code
> the patches are based on the work found on www.mobile-ipv6.org.
> I have no idea which code was written by whom so just email me
> t
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Mon, 31 Jul 2006 14:50:37 +0400
> In syscall time kevents copy 40bytes for each event + 12 bytes of header
> (number of events, timeout and command number). That's likely two cache
> lines if only one event is reported.
Do you know how many cachel
On Mon, Jul 31, 2006 at 08:35:55PM +1000, Herbert Xu ([EMAIL PROTECTED]) wrote:
> Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> >
> >> - if there is space, report it in the ring buffer. Yes, the buffer
> >> can be optional, then all events are reported by the system call.
> >
> > That requires
Wei Yongjun <[EMAIL PROTECTED]> wrote:
>
> I also send the same mail several ago, and get no response. You
> patch is fine. But I think following code has no effect:
>
> if (sk->sk_filter && skb->ip_summed != CHECKSUM_UNNECESSARY) {
>
> It just let UDP datagrams with checksum error be added into
Patrick McHardy wrote:
> David Miller wrote:
>
>>I would like to see this fixed for 2.6.18, no later.
>>
>>Either that or disable the bug trap, but taking this route
>>is severely discouraged. :)
>
>
> I'm actually updateing my patch for this on top of Herbert's
> CHECKSUM_PARTIAL patch right no
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
>> - if there is space, report it in the ring buffer. Yes, the buffer
>> can be optional, then all events are reported by the system call.
>
> That requires a copy, which can neglect syscall overhead.
> Do we really want it to be done?
Please note
On Sat, Jul 29, 2006 at 09:18:47AM -0700, Ulrich Drepper ([EMAIL PROTECTED])
wrote:
> Evgeniy Polyakov wrote:
> > Btw, why do we want mapped ring of ready events?
> > If user requestd some event, he definitely wants to get them back when
> > they are ready, and not to check and then get them?
> >
This change does not effect to tcpdump, only let UDP filter can not
received UDP datagrams with checksum error. It is not a good idea, but
I think is the best way to resolve this problem. If you want to capture
error UDP packet, you can used tcpdump.
On Monday 31 July 2006 04:57, Gerrit Renker wr
On Thu, Jul 27, 2006 at 11:44:23AM -0700, Ulrich Drepper wrote:
> Badari Pulavarty wrote:
> > Before we spend too much time cleaning up and merging into mainline -
> > I would like an agreement that what we add is good enough for glibc
> > POSIX AIO.
>
> I haven't seen a description of the interfa
This patch implements transparent ethernet bridging for gre tunnels.
There are a few outstanding issues.
There is no way for userspace to select the type of gre tunnel. The
#if 0 near the top of the patch forces all gre tunnels to be bridges.
The problem is that userspace uses an IPPROTO_ to selec
Hello.
The patch seems sane to me.
In article <[EMAIL PROTECTED]> (at Tue, 01 Aug 2006 05:45:39 -0400), weidong
<[EMAIL PROTECTED]> says:
> signed-off-by: Wei Dong <[EMAIL PROTECTED]>
Acked-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
--yoshfuji
-
To unsubscribe from this list: send the line "uns
Hello.
Next time, please put your "Signed-off-by" line before the patch.
Thank you.
In article <[EMAIL PROTECTED]> (at Tue, 01 Aug 2006 05:45:33 -0400), weidong
<[EMAIL PROTECTED]> says:
> signed-off-by:Wei Dong <[EMAIL PROTECTED]>
Acked-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
--yoshfuji
-
T
Hello,
[ resend because .config and the used kernel version was missing ]
Linux Kernel Version: Linus Vanilla Tree; .config attached.
I recently aquired a Lenovo (IBM) T60 with a e1000 network card. I
experience high latency with this networkcard: Pings last upto 1 second
where the ping shoul
In udp_queue_rcv_skb(), checksum condition is error. When UDP filter is
set, checksum is be done, but if UDP filter is not set, checksum will
not be done. So I think this is a BUG. Following is my patch:
--- a/net/ipv4/udp.c2006-07-31 09:33:45.392479344 -0400
+++ b/net/ipv4/udp.c2006-07-31
Hi, All
When I tested Linux kernel 2.6.17.7 about statistics
"ipv6IfStatsInHdrErrors", found that this counter couldn't increase
correctly. The criteria is RFC2465:
ipv6IfStatsInHdrErrors OBJECT-TYPE
SYNTAX Counter3
MAX-ACCESS read-only
STATUS current
DESCRIPTION
Hi, All
When I tested linux kernel 2.6.71.7 about statistics
"ipv6IfStatsOutFragCreates", and found that it couldn't increase
correctly. The criteria is RFC 2465:
ipv6IfStatsOutFragCreates OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCR
On Sun, Jul 30, 2006 at 10:32:10PM -0500, Matt Domsch wrote:
>
> I applied this on 2.6.18-rc3, and it panics immediately as the first
> IPv6 TCP (ssh) session is initiated to the system.
Executive summary:
1) We resolved one lockdep warning only to stumble onto another lockdep
validator bug.
Yes, you are right.
I also send the same mail several ago, and get no response. You
patch is fine. But I think following code has no effect:
if (sk->sk_filter && skb->ip_summed != CHECKSUM_UNNECESSARY) {
It just let UDP datagrams with checksum error be added into UDP receive
queue, and then dis
Hi,
| if (!sk->sk_filter && skb->ip_summed != CHECKSUM_UNNECESSARY) {
|
| IPv6 doesn't do this, so I think delete condition 'sk->sk_filter' is better.
| Do you think so?
I think the sk->sk_filter is there for a good reason. If you delete it, that
routine
is forced to always compute UDP ch
This has been raised earlier, cf.
http://bugzilla.kernel.org/show_bug.cgi?id=6660
Wei Yongjun wrote:
| When I send a UDP datagrams with checksum error to target, I found that:
| Under IPv6, counter udpInErrors increased, but under IPv4 counter
| udpInDatagrams increased. I lookup into the sour
On Monday 31 July 2006 05:50, you wrote:
> From: Ben Greear <[EMAIL PROTECTED]>
> Date: Fri, 28 Jul 2006 14:55:17 -0700
>
> > The skb_bond method assigns skb->dev when it does the 'keep',
> > but the VLAN code immediately over-writes the skb->dev when
> > searching for the vlan device.
> >
> > What
When I send a UDP datagrams with checksum error to target, I found that:
Under IPv6, counter udpInErrors increased, but under IPv4 counter
udpInDatagrams increased. I lookup into the source code, and found that,
under IPv4 UDP datagrams with checksum error will be delivered to UDP
receive queue, bu
97 matches
Mail list logo
