On Thu, Jul 20, 2006 at 09:55:04PM -0700, David Miller ([EMAIL PROTECTED])
wrote:
From: Alexey Kuznetsov [EMAIL PROTECTED]
Date: Fri, 21 Jul 2006 02:59:08 +0400
Moving protocol (no matter if it is TCP or not) closer to user allows
naturally control the dataflow - when user can read that
On Thu, Jul 20, 2006 at 02:21:57PM -0700, Ben Greear ([EMAIL PROTECTED]) wrote:
Out of curiosity, is it possible to have the single producer logic
if you have two+ ethernet interfaces handling frames for a single
TCP connection? (I am assuming some sort of multi-path routing
logic...)
I do
On Fri, Jul 21, 2006 at 11:19:00AM +0400, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
On Thu, Jul 20, 2006 at 02:21:57PM -0700, Ben Greear ([EMAIL PROTECTED])
wrote:
Out of curiosity, is it possible to have the single producer logic
if you have two+ ethernet interfaces handling frames for
On Fri, Jul 21, 2006 at 09:40:32AM +1200, Ian McDonald ([EMAIL PROTECTED])
wrote:
If we consider netchannels as how Van Jackobson discribed them, then
mutext is not needed, since it is impossible to have several readers or
writers. But in socket case even if there is only one userspace
From: Evgeniy Polyakov [EMAIL PROTECTED]
Date: Fri, 21 Jul 2006 11:10:10 +0400
On Thu, Jul 20, 2006 at 09:55:04PM -0700, David Miller ([EMAIL PROTECTED])
wrote:
Correct, and too large delay even results in retransmits. You can say
that RTT will be adjusted by delay of ACK, but if user
On Fri, Jul 21, 2006 at 12:47:13AM -0700, David Miller ([EMAIL PROTECTED])
wrote:
Correct, and too large delay even results in retransmits. You can say
that RTT will be adjusted by delay of ACK, but if user context
switches cleanly at the beginning, resulting in near immediate ACKs,
From: Evgeniy Polyakov [EMAIL PROTECTED]
Date: Fri, 21 Jul 2006 13:06:11 +0400
Receiving side, nor matter if it is socket or netchannel, will drop
packets (socket due to queue overfull, netchannels will not drop, but
will not ack (it's maximum queue len is 1mb)).
So both approaches behave
On Fri, Jul 21, 2006 at 02:19:55AM -0700, David Miller ([EMAIL PROTECTED])
wrote:
From: Evgeniy Polyakov [EMAIL PROTECTED]
Date: Fri, 21 Jul 2006 13:06:11 +0400
Receiving side, nor matter if it is socket or netchannel, will drop
packets (socket due to queue overfull, netchannels will not
From: Evgeniy Polyakov [EMAIL PROTECTED]
Date: Fri, 21 Jul 2006 13:39:09 +0400
On Fri, Jul 21, 2006 at 02:19:55AM -0700, David Miller ([EMAIL PROTECTED])
wrote:
From: Evgeniy Polyakov [EMAIL PROTECTED]
Date: Fri, 21 Jul 2006 13:06:11 +0400
Receiving side, nor matter if it is socket
We apologize for multiple receipts.
Eighth Real-Time Linux Workshop
October 12-15, 2006
Lanzhou University - SISE
Compiling (an exotic ?) config I got:
...
CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
drivers/built-in.o: In function `bnx2_set_rx_mode':
bnx2.c:(.text+0xd741e): undefined reference to `crc32_le'
drivers/built-in.o: In function `bnx2_test_nvram':
Igor V. Liferenko [EMAIL PROTECTED] wrote:
Would you please say why it's 60, and not 52?
The header length / 4 must fit within a single hexadecimal
digit. Therefore the maximum is 15 * 4 = 60.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Hi Francois,
Francois Romieu wrote:
Despite the fact that the newer 8168 has been reported to only work with an
extra alignment (gross hack: s/NET_IP_ALIGN/8/), the serie seems otherwise
fine.
I'll submit an updated serie to correctly support the 8168.
Any word on the updated 8168 patch?
From: Panagiotis Issaris [EMAIL PROTECTED]
Removing useless casts
Signed-off-by: Panagiotis Issaris [EMAIL PROTECTED]
---
net/tipc/discover.c |2 +-
net/tipc/ref.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/tipc/discover.c b/net/tipc/discover.c
index
On Thu, 20 Jul 2006 10:34:23 -0700
Auke Kok [EMAIL PROTECTED] wrote:
Okay, perhaps this should be inserted as a comment into the driver,
and printk should be fixed to point at this explanation?
Can't we enable the driver with the bad checksum, then read the _real_
data?
no.
We're
On Fri, Jul 21, 2006 at 06:41:05AM -0700, Andrew Morton wrote:
It's completely not acceptable to run when the EEPROM checksum fails - you
might even be running with the wrong MAC address, or worse. Lets fix this
the
right way instead.
A printk which helps the user to understand all
Theodore Tso wrote:
On Fri, Jul 21, 2006 at 06:41:05AM -0700, Andrew Morton wrote:
It's completely not acceptable to run when the EEPROM checksum fails - you
might even be running with the wrong MAC address, or worse. Lets fix this the
right way instead.
A printk which helps the user to
With struct sock and ax25_cb in a unified data structure it now is
possible to fix the reference counting by using the sk_reset_timer
and sk_stop_timer helper function - the previous implementation was
based simply on principle hope.
Signed-off-by: Ralf Baechle [EMAIL PROTECTED]
Evgeniy Polyakov wrote:
On Thu, Jul 20, 2006 at 02:21:57PM -0700, Ben Greear ([EMAIL PROTECTED]) wrote:
Out of curiosity, is it possible to have the single producer logic
if you have two+ ethernet interfaces handling frames for a single
TCP connection? (I am assuming some sort of multi-path
All this talk reminds me of one thing, how expensive tcp_ack() is.
And this expense has nothing to do with TCP really. The main cost is
purging and freeing up the skbs which have been ACK'd in the
retransmit queue.
So tcp_ack() sort of inherits the cost of freeing a bunch of SKBs
which haven't
On Fri, Jul 21, 2006 at 09:14:39AM -0700, Ben Greear ([EMAIL PROTECTED]) wrote:
Out of curiosity, is it possible to have the single producer logic
if you have two+ ethernet interfaces handling frames for a single
TCP connection? (I am assuming some sort of multi-path routing
logic...)
I do
On 7/21/06, Ralf Baechle [EMAIL PROTECTED] wrote:
Aside of wanrouter AX.25 has also been the last member of struct
sock.sk_protinfo. With net/wanrouter being considered hopeless code and
an application-level solution being prefered these days this means we now
can delete sk_protinfo.
/me
bcm43xx_get_drvinfo in 2.6.18-rc2 unfortunately uses UTS_RELEASE as
driver version. I think this specific info can be obtained by other
ways.
Can you give bcm43xx a real version number and provide it via the
ethtool ioctl?
It will trigger a rebuild if the uname -r of the kernel to build
changes.
On Friday 21 July 2006 20:59, Olaf Hering wrote:
bcm43xx_get_drvinfo in 2.6.18-rc2 unfortunately uses UTS_RELEASE as
driver version. I think this specific info can be obtained by other
ways.
Can you give bcm43xx a real version number and provide it via the
ethtool ioctl?
I am not going to
On Fri, Jul 21, Michael Buesch wrote:
On Friday 21 July 2006 20:59, Olaf Hering wrote:
bcm43xx_get_drvinfo in 2.6.18-rc2 unfortunately uses UTS_RELEASE as
driver version. I think this specific info can be obtained by other
ways.
Can you give bcm43xx a real version number and provide
On Fri, Jul 21, 2006 at 09:03:23PM +0200, Michael Buesch wrote:
I am not going to maintain a bogus version number.
What about simply returning 1.0 and be done with it.
I don't think it matters. 1.0 is as bogus as any other value.
Put it to use! Increment it whenever there's a major change in
On Friday 21 July 2006 21:13, Jason Lunz wrote:
On Fri, Jul 21, 2006 at 09:03:23PM +0200, Michael Buesch wrote:
I am not going to maintain a bogus version number.
What about simply returning 1.0 and be done with it.
I don't think it matters. 1.0 is as bogus as any other value.
Put it to
Hi,
The following patches fix 2 minor issues in the myri10ge driver:
1) Always do a dummy RDMA after loading the firmware
2) Write the firmware in 256-bytes chunks
Please apply.
thanks,
Brice
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL
When writing the firmware to the NIC, the FIFO is 256-bytes long,
so we use 256-bytes chunks and a read to wait until the previous
write is done.
Signed-off-by: Brice Goglin [EMAIL PROTECTED]
---
drivers/net/myri10ge/myri10ge.c | 20
1 file changed, 8 insertions(+), 12
On Fri, Jul 21, 2006 at 09:27:23PM +0200, Michael Buesch wrote:
What is a major change? Why only on major change? Why not on
simple changes, too? Simple changes sometimes introduce bugs, too.
the version number has whatever meaning you choose to assign to it.
Including none, if you so choose.
On Friday 21 July 2006 21:49, Brice Goglin wrote:
When writing the firmware to the NIC, the FIFO is 256-bytes long,
so we use 256-bytes chunks and a read to wait until the previous
write is done.
Signed-off-by: Brice Goglin [EMAIL PROTECTED]
---
drivers/net/myri10ge/myri10ge.c | 20
From: Rick Jones [EMAIL PROTECTED]
Date: Fri, 21 Jul 2006 09:26:42 -0700
All this talk reminds me of one thing, how expensive tcp_ack() is.
And this expense has nothing to do with TCP really. The main cost is
purging and freeing up the skbs which have been ACK'd in the
retransmit queue.
From: [EMAIL PROTECTED]
Date: Fri, 21 Jul 2006 15:45:50 +0200
From: Panagiotis Issaris [EMAIL PROTECTED]
Removing useless casts
Signed-off-by: Panagiotis Issaris [EMAIL PROTECTED]
Applied, thanks.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message
On Fri, 21 Jul 2006 08:22:38 -0700
Auke Kok [EMAIL PROTECTED] wrote:
And if someone who understands all of these details could put a note
in the thinkwiki (say, here:
http://www.thinkwiki.org/wiki/Ethernet_Controllers#Intel_Gigabit_.2810.2F100.2F1000.29)
it would be greatly appreciated.
Michael Buesch wrote:
On Friday 21 July 2006 21:49, Brice Goglin wrote:
+myri10ge_pio_copy(mgp-sram + MYRI10GE_FW_OFFSET + i,
+ fw-data + i,
+ min(256U, (unsigned)(fw-size - i)));
+mb();
+
35 matches
Mail list logo
