From: Herbert Xu <[EMAIL PROTECTED]>
Date: Tue, 18 Apr 2006 22:32:04 +1000
> You're absolutely right about there being a problem with the TSO packet
> trimming code. The cause of this lies in the tcp_fragment() function.
>
> When we allocate a fragment for a completely non-linear packet the
> tr
From: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
Date: Wed, 19 Apr 2006 00:20:45 +0900 (JST)
> Following changesets fix several errors in extension header handling.
> I'd propose to push them (except 4/4, maybe) to -stable.
>
> [PATCH 1/4] [IPV6]: Ensure to have hop-by-hop options in our header of
>
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Tue, 18 Apr 2006 16:54:48 +1000
> Looking at this again, the root of this problem is the IGMPv3
> patch which started using the skb->nh.iph->protocol as a key.
>
> So what we really should do is make the protocol an explicit parameter
> to the ip_route_i
From: Alexey Kuznetsov <[EMAIL PROTECTED]>
Date: Wed, 19 Apr 2006 03:52:22 +0400
> Actually, this weird case in inet_get_route() is the only place, where
> a dummy skb is used and it is needed mostly to resolve multicast routes.
> In this case this fake skb really passes through all the engine, ev
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Wed, 19 Apr 2006 09:53:48 -0700
> Please put this in the next -stable load...
I already sent it to -stable.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at h
From: Christian Borntraeger <[EMAIL PROTECTED]>
Date: Wed, 19 Apr 2006 12:45:48 +0200
> As spinlock debugging still does not work with the qeth driver I
> want to pick up the discussion.
Does something like the patch below work?
But this all begs the question, what happens if you want to
dig int
From: Hua Zhong <[EMAIL PROTECTED]>
Date: Wed, 19 Apr 2006 12:01:06 -0700
> There is a missing initialization of err in sockfd_lookup_light() that could
> return random error for an invalid file handle.
>
> Signed-off-by: Hua Zhong <[EMAIL PROTECTED]>
Applied, thanks a lot for this bug fix.
-
T
ide skb_cloned check
I'll fix it like this:
diff-tree 5185db09f46ed64d520d09db6e93852e44106628 (from
3672558c6180ca28a7aa46765702467a37e58fc5)
Author: David S. Miller <[EMAIL PROTECTED]>
Date: Wed Apr 19 15:37:13 2006 -0700
[LLC]: Use pskb_trim_rcsum() in llc_fixup_skb().
MAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
diff --git a/net/bridge/netfilter/ebtables.c b/net/bridge/netfilter/ebtables.c
index 66bd932..84b9af7 100644
--- a/net/bridge/netfilter/ebtables.c
+++ b/net/bridg
From: James Morris <[EMAIL PROTECTED]>
Date: Sun, 16 Apr 2006 01:10:50 -0400 (EDT)
> So, I propose to introduce a secmark field (per the patch below), which is
> only present when enabled as a sub-feature of LSM. That is, it does not
> have any effect at all for the default kernel. As an integ
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Wed, 19 Apr 2006 15:59:25 -0700
> "David S. Miller" <[EMAIL PROTECTED]> wrote:
> >
> > An earlier variant of your patch was applied already, included below.
> > You'll need to submit the newer parts rela
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Thu, 20 Apr 2006 13:26:02 +1000
> On Thu, Apr 20, 2006 at 11:01:11AM +1000, herbert wrote:
> > Hi Dave:
> >
> > Since sk_stream_alloc_pskb takes an extra argument that accounts for
> > paged data all we need to do to account sk_buff overhead correctly
>
Herbert what do you think of this?
I know it might be better to check this right where we
make the manipulations, but this catch-all trap at the
end points seems to make sense and will catch other kinds
of errors.
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index c4619a4..60a7c5
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Thu, 20 Apr 2006 15:04:06 +1000
> On Wed, Apr 19, 2006 at 09:55:13PM -0700, David S. Miller wrote:
> > +static inline void skb_truesize_check(struct sk_buff *skb)
> > +{
> > + if (unlikely((int)skb->tr
From: jamal <[EMAIL PROTECTED]>
Date: Thu, 20 Apr 2006 06:58:45 -0400
> On Fri, 2006-14-04 at 15:05 -0700, David S. Miller wrote:
> > From: jamal <[EMAIL PROTECTED]>
> > Date: Thu, 13 Apr 2006 09:00:08 -0400
> >
> > > There is dependency on the
[ Maybe ask questions like this on "netdev" where the networking
developers hang out? Added to CC: ]
Van fell off the face of the planet after giving his presentation and
never published his code, only his slides.
I've started to make a slow attempt at implementing his ideas, nothing
but pure
From: Mike Christie <[EMAIL PROTECTED]>
Date: Thu, 20 Apr 2006 14:29:06 -0500
> I was wondering if it is ok to pass sendpage high mem pages. If a piece
> of code does this:
>
> struct socket *sock;
>
> sock->ops->sendpage(pg...)
>
> and pg is a highmem page will the network layer do the right t
From: Olof Johansson <[EMAIL PROTECTED]>
Date: Thu, 20 Apr 2006 16:33:05 -0500
> From the wiki:
>
> >3. Data copied by I/OAT is not cached
>
> This is a I/OAT device limitation and not a global statement of the
> DMA infrastructure. Other platforms might be able to prime caches
> with the DM
From: "Andrew Grover" <[EMAIL PROTECTED]>
Date: Thu, 20 Apr 2006 15:14:15 -0700
> First obviously it's a technology for RX CPU improvement so there's no
> benefit on TX workloads. Second it depends on there being buffers to
> copy the data into *before* the data arrives. This happens to be the
> c
From: Olof Johansson <[EMAIL PROTECTED]>
Date: Thu, 20 Apr 2006 18:33:43 -0500
> On Thu, Apr 20, 2006 at 03:14:15PM -0700, Andrew Grover wrote:
> > In
> > addition, there may be workloads (file serving? backup?) where we
> > could do a skb->page-in-page-cache copy and avoid cache pollution?
>
> Y
From: Rick Jones <[EMAIL PROTECTED]>
Date: Thu, 20 Apr 2006 18:00:37 -0700
> Actually, that brings-up a question - presently, and for reasons that
> are lost to me in the mists of time - netperf will "access" the buffer
> before it calls recv(). I'm wondering if that should be changed to an
>
From: Olof Johansson <[EMAIL PROTECTED]>
Date: Thu, 20 Apr 2006 22:04:26 -0500
> On Thu, Apr 20, 2006 at 05:27:42PM -0700, David S. Miller wrote:
> > Besides the control overhead of the DMA engines, the biggest thing
> > lost in my opinion is the perfect cache warming
From: Ingo Oeser <[EMAIL PROTECTED]>
Date: Sun, 23 Apr 2006 02:05:32 +0200
> On Saturday, 22. April 2006 15:49, Jörn Engel wrote:
> > That was another main point, yes. And the endpoints should be as
> > little burden on the bottlenecks as possible. One bottleneck is the
> > receive interrupt, wh
From: Jörn Engel <[EMAIL PROTECTED]>
Date: Sat, 22 Apr 2006 13:48:46 +0200
> Unless I completely misunderstand something, one of the main points of
> the netchannels if to have *zero* fields written to by both producer
> and consumer. Receiving and sending a lot can be expected to be the
> common
From: bert hubert <[EMAIL PROTECTED]>
Date: Sat, 22 Apr 2006 21:30:24 +0200
> On Thu, Apr 20, 2006 at 12:09:55PM -0700, David S. Miller wrote:
> > Going all the way to the socket is a large endeavor and will require a
> > lot of restructuring to do it right, so expec
From: Ingo Oeser <[EMAIL PROTECTED]>
Date: Sat, 22 Apr 2006 15:29:58 +0200
> On Saturday, 22. April 2006 13:48, Jörn Engel wrote:
> > Unless I completely misunderstand something, one of the main points of
> > the netchannels if to have *zero* fields written to by both producer
> > and consumer.
>
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Sat, 22 Apr 2006 15:22:54 +1000
> Jeff Garzik <[EMAIL PROTECTED]> wrote:
> >
> >> 05/10: [PATCH] Update truesize with the length of the packet for
> >> packet split
> >
> > These 10 patches look OK, but since the current kernel vers
From: Ingo Oeser <[EMAIL PROTECTED]>
Date: Fri, 21 Apr 2006 18:52:47 +0200
> nice to see you getting started with it.
Thanks for reviewing.
> I'm not sure about the queue logic there.
>
> 1867 /* Caller must have exclusive producer access to the netchannel. */
> 1868 int netchannel_enqueue(stru
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Tue, 25 Apr 2006 09:43:49 +0200
> On Tuesday 25 April 2006 09:31, John Que wrote:
> > Hello,
> > What is the right way to determine on which interface card
> > (eth0 or eth1) will a packet be sent (according to the dest IP)?
>
> You can send a rtnetlink
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Tue, 25 Apr 2006 10:01:49 -0700
> > # Hit# miss Function:[EMAIL PROTECTED]
> > ! 0 50505 tcp_transmit_skb():net/ipv4/[EMAIL PROTECTED]
...
> How about just taking off the likely/unlikely in this case.
Why remove it when we'l
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
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: 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
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: 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
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: 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: "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,
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
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
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: 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: 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: "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
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
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: 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: 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
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 issue
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Thu, 27 Apr 2006 08:41:51 +0200
> Yes but all clients will see all the data from all sockets don't
> they? [Unless you have a RDMA nic that can scale to hundred
> thousands of connections, but let's assume standard hardware for
> now]
Each netchannel, w
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Thu, 27 Apr 2006 15:51:26 +0400
> There are some caveats here found while developing zero-copy sniffer
> [1]. Project's goal was to remap skbs into userspace in real-time.
> While absolute numbers (posted to netdev@) were really high, it is only
> a
From: John Heffner <[EMAIL PROTECTED]>
Date: Thu, 27 Apr 2006 13:47:33 -0400
> (Most OS's don't do 2861, and it is not a standard.)
Are you so sure? Doing cwnd timeout largely predates the congestion
window validation work, in fact by several years.
In RFC 2581, it mentions Van Jacobson's recom
From: Auke Kok <[EMAIL PROTECTED]>
Date: Thu, 27 Apr 2006 18:54:28 -0700
> Dave Jones wrote:
> > With 2.6.17-rc3, my E1000 won't get a dhcp lease.
> > Looking at tcpdump and ifconfig output, it's easy to see why.
> > It's recieving packets, but the packets transmitted field
> > of ifconfig never i
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Fri, 28 Apr 2006 10:10:54 +0400
> On Thu, Apr 27, 2006 at 02:12:09PM -0700, Caitlin Bestler ([EMAIL PROTECTED])
> wrote:
> > So the real issue is when there is an intelligent device that
> > uses hardware packet classification to place the packet i
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Fri, 28 Apr 2006 11:32:16 +0400
> Definitely, userspace application must be very smart to deal with
> ip/tcp/option headers...
That is why we will put an "offset+len" in the ring so they need not
parse the packet headers.
-
To unsubscribe from thi
From: Shaun Pereira <[EMAIL PROTECTED]>
Date: Thu, 20 Apr 2006 15:03:23 +1000
> From: [EMAIL PROTECTED]
>
> When the sk_timer function x25_heartbeat_expiry() is called by the kernel
> in a running/terminating process, spinlock-recursion and spinlock-lockup
> locks up the kernel.
> This has happe
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Fri, 28 Apr 2006 20:12:21 +0400
> If there is dataflow, not flow of packets or flow of data with holes,
> it could be possible to modify recv() to just return the right pointer,
> so in theory userspace modifications would be minimal.
> With copy in
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Fri, 28 Apr 2006 10:18:33 -0700
> Please just use existing AIO interface.
I totally disagree, the existing AIO interface is garbage.
We need new APIs to do this right, to get the ring buffer
and the zero-copy'ness correct.
-
To unsubscribe from t
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Fri, 28 Apr 2006 10:22:40 -0700
> The following one line fix is needed to make loss function of
> netem work right when doing loss on the local host.
> Otherwise, higher layers just recover.
>
> Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Fri, 28 Apr 2006 21:25:36 +0400
> The more complex userspace interface we create the less users it will
> have. It is completely unconvenient to read 100 bytes and receive only
> 80, since 20 were eaten by header.
These bytes are charged to socket
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Fri, 28 Apr 2006 21:55:39 +0400
> On Fri, Apr 28, 2006 at 10:41:18AM -0700, Stephen Hemminger ([EMAIL
> PROTECTED]) wrote:
> > Second, introducing
> > kevents, seems unnecessary and hasn't been accepted in the mainline.
>
> kevent was never sent t
From: Rusty Russell <[EMAIL PROTECTED]>
Date: Fri, 28 Apr 2006 18:24:08 +1000
> Note that the problem space AFAICT includes strange advanced routing
> setups, ingress qos and possibly others, not just netfilter. But
> perhaps the same solutions apply, so I'll concentrate on nf.
Yes, this hasn't
From: S P <[EMAIL PROTECTED]>
Date: Fri, 28 Apr 2006 13:51:43 -0700 (PDT)
> 1 line removal, of unused macro.
> ran 'egrep -r' from linux-2.6.16/ for Nprintk and
> didn't see it anywhere else but here, in #define...
>
>
> signed off by: soyoung park
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Fri, 28 Apr 2006 23:59:30 +0400
> kevent can be used as poll without any changes to the socket code.
> There are two types of network related kevents - socket events
> (recv/send/accept) and network aio, which can be turned completely off
> in confi
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Thu, 27 Apr 2006 21:56:45 +1000
> I was looking through the xfrm input/output code in order to abstract
> out the address family specific encapsulation/decapsulation code. During
> that process I found this bug in the IP ID selection code in xfrm4_output
From: Hua Zhong <[EMAIL PROTECTED]>
Date: Wed, 26 Apr 2006 09:50:28 -0700 (PDT)
> [I hope this time it's OK - I'm sending from pine/Linux]
It adds an extra space in the diff lines which corrupts
the patch.
I've applied this by hand, but please try to get something
which works before providing ne
From: Rusty Russell <[EMAIL PROTECTED]>
Date: Sat, 29 Apr 2006 08:04:04 +1000
> You're still thinking you can bypass classifiers for established
> sockets, but I really don't think you can. I think the simplest
> solution is to effectively remove from (or flag) the established &
> listening hashe
From: Rusty Russell <[EMAIL PROTECTED]>
Date: Sat, 29 Apr 2006 08:17:01 +1000
> On Fri, 2006-04-28 at 10:55 -0700, Caitlin Bestler wrote:
> > vj_netchannels represent a strategy of minimizing
> > registration/pinning costs even if it means paying for an extra copy.
> > Because the extra copy is cl
From: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
Date: Fri, 28 Apr 2006 02:04:56 +0900 (JST)
> We eliminated rt6_dflt_lock (to protect default router pointer)
> at 2.6.17-rc1, and introduced rt6_select() for general router selection.
> The function is called in the context of rt6_lock read-lock held,
>
From: Rusty Russell <[EMAIL PROTECTED]>
Date: Sat, 29 Apr 2006 10:22:40 +1000
> You're thinking the card would place the packet in the mmap'ed buffer,
> but the protocol handling would still be done (on that user-accessible
> buffer) in kernelspace?
Exactly.
> I hadn't considered that. Are the
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Fri, 28 Apr 2006 16:35:06 -0700
> Add netif_carrier_off() call during tg3_phy_reset(). This is needed
> to properly track the netif_carrier state in cases where we do a
> PHY reset with interrupts disabled. The SerDes code will not run
> properly if t
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Fri, 28 Apr 2006 16:35:19 -0700
> Add some PHY workaround code to reduce jitter on some PHYs.
>
> Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
Applied, thanks.
It really bugs me that all of this indirect addressing into
the DSP is done with magi
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Fri, 28 Apr 2006 16:35:35 -0700
> Do the full chip reset when changing MAC address if ASF is enabled.
>
> ASF sometimes uses a different MAC address than the driver. Without
> the reset, the ASF MAC address may be overwritten when the driver's
> MAC
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Fri, 28 Apr 2006 16:36:08 -0700
> Add a reset_phy parameter to tg3_reset_hw() and tg3_init_hw(). With
> the full chip reset during MAC address change, the automatic PHY reset
> during chip reset will cause a link down and bonding will not work
> prope
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Fri, 28 Apr 2006 16:36:21 -0700
> Fix bug in nvram write function. If the starting nvram address offset
> happens to be the last dword of the page, the NVRAM_CMD_LAST bit will
> not get set in the existing code. This patch fixes the bug by changing
>
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Fri, 28 Apr 2006 16:36:30 -0700
> Update version to 3.57.
>
> Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
Applied.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo i
At least for the TG3PCI_MEM_WIN_DATA register, I don't know how safe
it is to use tw32_f() there. Reads from a location can have side
effects, so doing a forced readback after a write could be dangerous.
And it isn't needed, as the tw32_f() done as we set the
TG3PCI_MEM_WIN_BASE_ADDR back to zer
From: Bernard Pidoux <[EMAIL PROTECTED]>
Date: Sun, 30 Apr 2006 21:34:32 +0200
> Ralf Baechle wrote :
>
> > Convert all NET/ROM sysctl time values from jiffies to ms as units.
> >
> > Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]>
> >
>
> With such extensive patches for netrom and rose module
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Sun, 30 Apr 2006 22:05:40 -0700
> Reading back the data register is a safe thing to do. This
> guarantees that the data is written before we change the address
> register to the zero value. Without the read, there is a danger of
> the value being writ
Ralf, I have all of your patches queued up, I'll review them
and merge them in soon.
Thanks a lot.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Sat, 29 Apr 2006 16:44:51 +0400
> Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
I understand how in some ways this is work in progress,
but direct calls into ext3 from the kevent code? I'd
like stuff like that cleaned up before reviewing :-)
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Tue, 2 May 2006 18:02:43 +0200
> On Tuesday 02 May 2006 18:19, Just Marc wrote:
>
> > I thought that maybe it's time to either set TCP_DEBUG to 0 or
> > alternatively allow an admin to toggle the printing of this message
> > off/on? On a few busy web
I don't think we should be defining driver APIs when we haven't even
figured out how the core of it would even work yet.
A key part of this is the netfilter bits, that will require
non-trivial flow identification, a hash will simply not be enough, and
it will not be allowed to not support the net
BTW another thing to keep in mind, besides the fact that we should be
designing driver APIs at this point at all, is that no implementation
should do MMIOs to the card to insert or delete netchannel lookup
entries.
Rather, it should be communicated to the card in a lazy fashion using
DMA.
Otherw
From: "Leonid Grossman" <[EMAIL PROTECTED]>
Date: Wed, 3 May 2006 09:56:18 -0400
> Do you have suggestions on potential hardware assists/offloads for
> netfilter?
We don't know yet what things will look like, that's why we
shouldn't be defining APIs and I cannot give any such advice
yet.
-
To uns
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Wed, 3 May 2006 22:07:40 +0400
> On Wed, May 03, 2006 at 08:56:23AM -0700, Caitlin Bestler ([EMAIL PROTECTED])
> wrote:
> > > I'd expect high end NIC ASICs to implement rx steering based
> > > upon some sort of hash (for load balancing), as well as
From: Ralf Baechle <[EMAIL PROTECTED]>
Date: Sat, 29 Apr 2006 14:25:53 +0100
> Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]>
Applied, thanks.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.ker
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Sat, 29 Apr 2006 23:13:20 +1000
> On Sat, Apr 29, 2006 at 09:15:07PM +1000, herbert wrote:
> >
> > Unfortunately this is only true for TCP. All of the connectionless
> > protocols use the callback lock without the socket lock so it does
> > still serve
From: Ralf Baechle DL5RB <[EMAIL PROTECTED]>
Date: Sat, 29 Apr 2006 15:24:27 +0100
> Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]>
Applied.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kerne
From: Ralf Baechle DL5RB <[EMAIL PROTECTED]>
Date: Sat, 29 Apr 2006 15:29:43 +0100
> Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]>
Applied, thanks.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vg
From: Ralf Baechle DL5RB <[EMAIL PROTECTED]>
Date: Sat, 29 Apr 2006 15:34:13 +0100
> Signed-off-by: Ralf Baechle DL5RB <[EMAIL PROTECTED]>
Applied.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger
From: Ralf Baechle <[EMAIL PROTECTED]>
Date: Sat, 29 Apr 2006 14:40:23 +0100
> Move AX.25 symbol exports to next to their definitions where they're
> supposed to be these days.
>
> Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]>
Applied.
-
To unsubscribe from this list: send the line "unsubscrib
From: Ralf Baechle <[EMAIL PROTECTED]>
Date: Sat, 29 Apr 2006 14:31:41 +0100
> The locking rule for rose_remove_neigh() are that the called needs to
> hold rose_neigh_list_lock, so we better don't take it yet again in
> rose_neigh_list_lock.
>
> Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]>
Ap
From: Ralf Baechle DL5RB <[EMAIL PROTECTED]>
Date: Sat, 29 Apr 2006 15:12:44 +0100
> Convert all AX.25 sysctl time values from jiffies to ms as units.
>
> Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]>
Applied.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a
From: Ralf Baechle <[EMAIL PROTECTED]>
Date: Sat, 29 Apr 2006 15:16:13 +0100
> Convert all NET/ROM sysctl time values from jiffies to ms as units.
>
> Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]>
Applied.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a mes
From: Ralf Baechle <[EMAIL PROTECTED]>
Date: Sat, 29 Apr 2006 15:19:24 +0100
> Convert all ROSE sysctl time values from jiffies to ms as units.
>
> Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]>
Applied.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a messag
From: Patrick Caulfield <[EMAIL PROTECTED]>
Date: Thu, 27 Apr 2006 13:37:23 +0100
> This patch fixes hello messages sent when a node is a level 1 router. Slightly
> contrary to the spec (maybe) VMS ignores hello messages that do not name
> level2 routers that it also knows about.
>
> So, here we
From: Alex Aizman <[EMAIL PROTECTED]>
Date: Thu, 04 May 2006 15:49:11 -0700
> So, what are the requirements?
I will say it a 10th time, "we simply don't know yet."
Please be patient and let us design the net channel infrastructure
properly, then we can think clearly about how hardware might supp
From: Kelly Daly <[EMAIL PROTECTED]>
Date: Thu, 4 May 2006 17:28:27 +1000
> On Wednesday 26 April 2006 17:59, David S. Miller wrote:
> > Next, you can't even begin to work on the protocol channels before you
> > do one very important piece of work. Integration of al
From: Kelly Daly <[EMAIL PROTECTED]>
Date: Thu, 4 May 2006 12:59:23 +1000
> We DID write an infrastructure to resolve this issue, although it is more
> complex than the dynamic descriptor scheme for userspace. And we want to
> keep this simple - right?
Yes.
I wonder if it is possible to manag
101 - 200 of 1576 matches
Mail list logo
