David Stevens <[EMAIL PROTECTED]> wrote:
>You're right, I don't know whether it'll fix the problem Ben saw
> or not, but it looks like the original code can do a receive before the
> in_device is fully initialized, and that, of course, is bad.
>If the device for ip_rcv() is not the
Ben,
If the ip_rcv() and the inetdev_init() are on the same
interface in your stack backtrace, it's a certainty at that point
that the lock value is still 0ed, because none of the initialization
occurs until after it has returned from the function it interrupted
to do the receive.
Herbert,
You're right, I don't know whether it'll fix the problem Ben saw
or not, but it looks like the original code can do a receive before the
in_device is fully initialized, and that, of course, is bad.
If the device for ip_rcv() is not the same one we were
initializing when the
> If you think I should not add the udata parameter to the req_notify_cq()
> provider verb, then I can rework the chelsio driver:
>
> 1) at cq creation time, pass the virtual address of the u32 used by the
> library to track the current cq index. That way the chelsio kernel
> driver can save the
Trivial. Newlines missing on the SOCK_DEBUG's for X.25 facility negotiation.
Signed-off-by: Andrew Hendry <[EMAIL PROTECTED]>
--- linux-2.6.19-vanilla/net/x25/x25_facilities.c 2006-12-31
22:31:07.0 +1100
+++ linux-2.6.19/net/x25/x25_facilities.c 2007-01-01 22:56:17.0
View the active forwarded call list
cat /proc/net/x25/forward
Signed-off-by: Andrew Hendry <[EMAIL PROTECTED]>
--- linux-2.6.19-vanilla/net/x25/x25_proc.c 2006-12-31 22:31:07.0
+1100
+++ linux-2.6.19/net/x25/x25_proc.c 2007-01-01 19:16:56.0 +1100
@@ -165,6 +165,75 @@ out:
Adds call forwarding to X.25, allowing it to operate like an X.25 router.
Useful if one needs to manipulate X.25 traffic with tools like tc.
This is an update/cleanup based off a patch submitted by Daniel Ferenci a few
years ago.
Worked ok with Cisco XoT, linux X.25 back to back, and some old NTU
Tested by Marijn Schouten
zd1211b chip 0586:340f v4810 high 00-13-49 AL2230_RF pa0 g---
FCC ID: I88G220V2
Signed-off-by: Daniel Drake <[EMAIL PROTECTED]>
---
zd_usb.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
Index: linux/drivers/net/wireless/zd1211rw/zd_usb.c
==
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Date: Wed, 03 Jan 2007 16:40:02 +1100
> On the quad G5 which has tg3, I get "Flow control is on for TX and on
> for RX". Let me double check if I'm on the same switch...
>
> Heh ! It's not :-)
>
> If I switch the cables, then pause is enabled on t
From: Adrian Bunk <[EMAIL PROTECTED]>
Date: Thu, 4 Jan 2007 00:09:28 +0100
> This patch adds a proper prototype for x25_init_timers() in
> include/net/x25.h
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Applied, thanks Adrian.
-
To unsubscribe from this list: send the line "unsubscribe net
From: Gerrit Renker <[EMAIL PROTECTED]>
Date: Wed, 3 Jan 2007 08:08:08 +
> However, I would also like to plead non-guilty. I have checked - what you
> are quoting is not the original patch. If you look at e.g. 2.6.17-mm1, the
> previous code had the form (this is copied from 2.6.17-mm1 origin
Ben Greear <[EMAIL PROTECTED]> wrote:
>
> I'm not sure if it helps..but I did notice that 'ip' was using 99% of the
> CPU on the system. Could this be because it was spinning trying to acquire
> the read-lock? When I ran 'ifconfig -a', that process hung, and at that point
> the system was reboot
Herbert Xu wrote:
David Stevens <[EMAIL PROTECTED]> wrote:
Ben,
Here's a patch that I think will fix it, assuming the receive is
on the
same device as the initialization. Can you try this out?
Hi David:
Your patch makes sense on its own but I don't see the direct connection
to the so
On Wed, 2007-01-03 at 15:46 -0800, Andrew Morton wrote:
>
> Begin forwarded message:
>
> Date: Wed, 3 Jan 2007 11:54:26 +
> From: Steve Hill <[EMAIL PROTECTED]>
> To: Linux Kernel Mailing List
> Subject: Intermittent SCTP multihoming breakage
>
>
>
> Apologies if I'm posting to the wrong
Linux 2.6.19 (but this problem occurs with previous kernels too)
gcc 4.1.1
pentium 3
Module dmfe.ko
dmfe: Davicom DM9xxx net driver, version 1.36.4 (2002-01-17)
eth0: Davicom DM9102 at pci:00:10.0, 00:d0:09:18:e1:8a, irq 5.
00:10.0 Ethernet controller: Davicom Semiconductor, Inc. Ethernet 100
Gerrit Renker <[EMAIL PROTECTED]> wrote:
>
>size = 0;
>sk_for_each(sk2, node, list)
>if (++size >= best_size_so_far)
>goto next;
>best_size_so_far = size;
When accessing the 93LC86 serial prom the clock high and low times must be at
least 250ns each. We have seen on some systems where the access times were
much lower casing bit errors.
Signed-off-by: Ron Mercer <[EMAIL PROTECTED]>
---
drivers/net/qla3xxx.c | 37 +++--
Qlogic 4032 chip is an incremental change from the 4022.
Signed-off-by: Ron Mercer <[EMAIL PROTECTED]>
---
drivers/net/qla3xxx.c | 363 +
drivers/net/qla3xxx.h | 88 +++-
2 files changed, 379 insertions(+), 72 deletions(-)
diff --git a/dr
Driver TX locking was removed some time ago, but the flag was overlooked.
Signed-off-by: Ron Mercer <[EMAIL PROTECTED]>
---
drivers/net/qla3xxx.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/qla3xxx.c b/drivers/net/qla3xxx.c
index d79d141..36e0830 100644
---
David Stevens <[EMAIL PROTECTED]> wrote:
>
> Ben,
>Here's a patch that I think will fix it, assuming the receive is
> on the
> same device as the initialization. Can you try this out?
Hi David:
Your patch makes sense on its own but I don't see the direct connection
to the soft lock-up.
Re-organized previous 5 patches into 3 patches.
1. Bug fix - remove NETIF_F_LLTX flag from features.
2. Bug fix - Add delay to NVRAM access. See patch for detailed answer to your
questions.
3. Combined patches 1 and 5 that add new chip support (and fixed bug in first
1/5 patch).
(removed patch
Gerrit Renker <[EMAIL PROTECTED]> wrote:
>
> | Prior to the patch, we have values x and y such that both
> | before(x, y) and before(y, x) are true. Now for those same
> | values both before(x, y) and before(y, x) are false.
> |
> | It's still as ambiguous as ever. Surely to resolve the
> |
OK, sounds good.
By the way, I think you can probably hit it more often if you have
something on the virtual network sending lots of multicast traffic while
you're creating the interface. That'll increase the odds that you'll
get into ip_check_mc() with a partially initialized in_dev.
You can use
Begin forwarded message:
Date: Wed, 3 Jan 2007 11:54:26 +
From: Steve Hill <[EMAIL PROTECTED]>
To: Linux Kernel Mailing List
Subject: Intermittent SCTP multihoming breakage
Apologies if I'm posting to the wrong list - the lksctp lists seem to be a
bit dead these days and a bit of Googlin
See my comments below.
Regards
///jon
Jarek Poplawski wrote:
..
Maybe I misinterpret this but, IMHO lockdep
complains about locks acquired in different
order: tipc_ref_acquire() gets ref_table_lock
and then tipc_ret_table.entries[index]->lock,
but tipc_deleteport() inversely (with:
t
David Stevens wrote:
Ben,
Here's a patch that I think will fix it, assuming the receive is
on the
same device as the initialization. Can you try this out?
We are attempting to reproduce this now...as soon as we can reproduce,
I'll apply this and see if that fixes the problem. This ra
Hello,
I have been trying to get RED with ECN working on 2.6.x kernel for a few weeks
now without any positive results. My setup is as follows
A 2.6.15 kernel running on a linux box configured as a router. I used the
following command to add/replace the existing default qdisc of the NIC
tc qdi
Ben,
Here's a patch that I think will fix it, assuming the receive is
on the
same device as the initialization. Can you try this out?
+-DLS
[inline for viewing, attached for applying]
Signed-off-by: David L Stevens <[EMAIL PROTECTED]>
diff
This patch adds a proper prototype for x25_init_timers() in
include/net/x25.h
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
include/net/x25.h |1 +
net/x25/af_x25.c |2 --
2 files changed, 1 insertion(+), 2 deletions(-)
--- linux-2.6.20-rc2-mm1/include/net/x25.h.old 2007-01-03
Please pull from tag 'qla3xxx-upstream-fixes-20070103-00' in repository
git://electric-eye.fr.zoreil.com/home/romieu/linux-2.6.git tag
qla3xxx-upstream-fixes-20070103-00
to get the changes below.
Distance from 'netdev-2.6
Ben & Jarek,
Your analysis looks correct to me. It seems to me the problem is
that
we don't want the in_device to be searchable until after the
initialization is done.
What about moving the initialization of dev->ip_ptr in inetdev_init() to
after the
"out" label?
On 1/2/07, Eric Piel <[EMAIL PROTECTED]> wrote:
Hi, I've been using e100 for years with no problem, however more by
curiosity than necessity I'd like to know how will be handled the
devices which are (supposedly) supported by eepro100 and not by e100?
According to "modinfo eepro100" and "modinfo
This patch contains a fix that implements proper communication with the
sideband management unit. Also, it makes sure that the speed is
correctly set for gigabit phys in the case where sideband mgmt unit
initialized the phy. Refer to bug #7684 for more details.
Signed-Off-By: Ayaz Abdulla <[EM
> >
> > So what does this tell you?
> > To me it looks like there's a measurable speed difference,
> > and so we should find a way (e.g. what I proposed) to enable chelsio
> > userspace
> > without adding overhead to other low level drivers or indeed chelsio kernel
> > level code.
> >
> > What
This email lists some known regressions in 2.6.20-rc3 compared to 2.6.19
with patches available.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any oth
This email lists some known regressions in 2.6.20-rc3 compared to 2.6.19
that are not yet fixed in Linus' tree.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering
On Tuesday, January 2 2007 6:37 pm, David Miller wrote:
> From: Paul Moore <[EMAIL PROTECTED]>
> Date: Tue, 2 Jan 2007 16:25:24 -0500
>
> > I'm sorry I just saw this mail (mail not sent directly to me get
> > shuffled off to a folder). I agree with your patch, I think
> > dropping and then re-taki
This patch removes the crc-itu-t files from rt2x00
and makes sure rt2x00 will use the generic crc-itu-t
implementation inside the lib folder.
Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]>
---
diff -rNU3 wireless-dev/drivers/net/wireless/d80211/rt2x00/Kconfig
wireless-dev_crc/drivers/net/wirel
This patch removes the eeprom_93cx6 files from rt2x00
and makes sure rt2x00 will use the generic eeprom_93cx6
implementation inside the lib folder.
Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]>
---
diff -rNU3 wireless-dev/drivers/net/wireless/d80211/rt2x00/Kconfig
wireless-dev_eeprom/drivers/
This patch adds the eeprom_93cx6 module to the lib folder.
This module provides a generic approach for reading and
writing words from the eeprom chipsets 93c46 and 93c66.
Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]>
---
diff -rNU3 wireless-dev/include/linux/eeprom_93cx6.h
wireless-dev_eeprom
This patch add the crc-itu-t implementation to the
lib folder.
This crc handler uses the CRC ITU-T V.41 routine
that is used in multiple drivers.
Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]>
---
diff -rNU3 wireless-dev/include/linux/crc-itu-t.h
wireless-dev_crc/include/linux/crc-itu-t.h
---
Hi John,
These patches have been send during 2006 but never
have been applied or rejected. Even after sending requests
for updates on these patches.
So I have no idea if you had rejected them, simply
overlooked them, or if they are still in your pending list.
Short summary of which patches are be
On Wed, 2007-01-03 at 21:33 +0200, Michael S. Tsirkin wrote:
> > Without extra param (1000 iterations in cycles):
> > ave 101.283 min 91 max 247
> > With extra param (1000 iterations in cycles):
> > ave 103.311 min 91 max 221
>
> A 2% hit then. Not huge, but 0 either.
>
> > Convert cycle
> Without extra param (1000 iterations in cycles):
> ave 101.283 min 91 max 247
> With extra param (1000 iterations in cycles):
> ave 103.311 min 91 max 221
A 2% hit then. Not huge, but 0 either.
> Convert cycles to ns (3466.727 MHz CPU):
>
> Without: 101.283 / 3466.727 = .02922us =
On Wed, Jan 03, 2007 at 05:33:57PM +0100, KOVACS Krisztian wrote:
> The following set of patches implement transparent proxying support
> loosely modeled on the Linux 2.2 transparent proxying functionality.
In a transparent http proxy server I wrote a while ago, we used to use
tproxy for making o
> > > > ib_set_cq_udata() would transition into the kernel to pass in the
> > > > consumer's index. In addition, ib_req_notify_cq would also transition
> > > > into the kernel since its not a bypass function for chelsio.
> > >
> > > We misunderstand each other.
> > >
> > > ib_uverbs_req_notify_c
Jiri Benc wrote:
> On Wed, 03 Jan 2007 19:10:01 +0100, Jan Kiszka wrote:
>> BUG: warning at
>> /usr/src/rt2x00/rt2x00/ieee80211/ieee80211.c:1256/ieee80211_tx()
>> ieee80211_master_start_xmit+0x105/0x430 [80211]
>> __ip_ct_refresh_acct+0x4d/0x60
>> tcp_packet+0x941/0x970 qdisc_restart+0x92
On Wed, 03 Jan 2007 19:10:01 +0100, Jan Kiszka wrote:
> BUG: warning at
> /usr/src/rt2x00/rt2x00/ieee80211/ieee80211.c:1256/ieee80211_tx()
> ieee80211_master_start_xmit+0x105/0x430 [80211]
> __ip_ct_refresh_acct+0x4d/0x60
> tcp_packet+0x941/0x970 qdisc_restart+0x92/0x100
> dev_queue_xmi
Jiri Benc wrote:
> On Tue, 02 Jan 2007 14:08:21 +0100, Jan Kiszka wrote:
>
>> What I (think to) understand is that a low-level drivers call
>> ieee80211_stop_queue() if they run out of buffers. That flips a
>> per-queue bit (IEEE80211_LINK_STATE_XOFF), prevents that any further
>> frame is pass
From: David Kimdon <[EMAIL PROTECTED]>
If we are already authenticating don't send another authentication
request.
Signed-off-by: David Kimdon <[EMAIL PROTECTED]>
Signed-off-by: Jiri Benc <[EMAIL PROTECTED]>
---
net/d80211/ieee80211_sta.c |2 +-
1 files changed, 1 insertions(+), 1 deletion
From: Jan Kiszka <[EMAIL PROTECTED]>
Switching the interface mode with some encryption keys set and then later
touching any key, triggers an oops because ieee80211_if_reinit fails to
NULL'ify the related pointers after free'ing the key on mode change. Long
explanation, simple fix below.
Signed-of
From: David Kimdon <[EMAIL PROTECTED]>
The 'associated' flag might be set if a previous association did not
end cleanly. If the 'associated' flag is left set here then when
association succeeds ieee80211_set_associated() will think there is
nothing to report and will not inform userspace of the e
When ops->hw_scan is set, scan_work is never initialized thus canceling it
causes weird problems.
Signed-off-by: Jiri Benc <[EMAIL PROTECTED]>
---
net/d80211/ieee80211.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
82c4e75463da9d3f38540198c4594cafe336b3e1
diff --git a/net/d80
From: Johannes Berg <[EMAIL PROTECTED]>
This just adds a missing \n I noticed when I got the warning (see my
other mail)
Signed-off-by: Johannes Berg <[EMAIL PROTECTED]>
Signed-off-by: Jiri Benc <[EMAIL PROTECTED]>
---
net/d80211/ieee80211.c |2 +-
1 files changed, 1 insertions(+), 1 delet
ieee80211_register_hwmode is allowed to be called before ieee80211_register_hw.
Signed-off-by: Jiri Benc <[EMAIL PROTECTED]>
---
include/net/d80211.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
acc7a635825dfc3b077630d8be621504ac71637e
diff --git a/include/net/d80211.h b/include
From: Michael Buesch <[EMAIL PROTECTED]>
const-ify the ieee80211_ops pointer to allow
* The compiler to do opimizations
* The drivers to declare this structure const.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Signed-off-by: Jiri Benc <[EMAIL PROTECTED]>
---
include/net/d80211.h |
From: Michael Buesch <[EMAIL PROTECTED]>
This turns the PHY-modes list into a linked list.
The advantage is that drivers can add modes dynamically, as they probe
them and don't have to settle to a given arraysize at the beginning
of probing.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Signe
The switch in classify_1d can be simplified to a bit operation.
Signed-off-by: Jiri Benc <[EMAIL PROTECTED]>
---
net/d80211/wme.c | 19 ++-
1 files changed, 2 insertions(+), 17 deletions(-)
e874890656210a235fbcfe0935717f86e5d179d9
diff --git a/net/d80211/wme.c b/net/d80211/wm
From: Michael Buesch <[EMAIL PROTECTED]>
Fix several warnings due to incompatible datatypes on
64bit platforms.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Signed-off-by: Jiri Benc <[EMAIL PROTECTED]>
---
net/d80211/ieee80211_sta.c |9 ++---
1 files changed, 6 insertions(+), 3 de
From: Zhu Yi <[EMAIL PROTECTED]>
I don't see any reason why packets with DSCP=0x40 should have lower IEEE
802.1D priority than packets with DSCP=0x20. Spare > Background. No?
Signed-off-by: Zhu Yi <[EMAIL PROTECTED]>
Signed-off-by: Jiri Benc <[EMAIL PROTECTED]>
---
net/d80211/wme.c |4 ++--
From: Michael Buesch <[EMAIL PROTECTED]>
ieee80211_hw pointers have to be passed to ops->set_key()
and ops->get_tsf().
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Signed-off-by: Jiri Benc <[EMAIL PROTECTED]>
---
net/d80211/ieee80211_iface.c |4 ++--
net/d80211/ieee80211_sta.c |
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/jbenc/dscape.git up2
to obtain following patches:
David Kimdon:
d80211: clear ifsta->associated flag when authentication starts
d80211: inhibit duplicate authentication requests when setting bssid
Jan Kiszka:
d80211:
On Tue, 02 Jan 2007 14:08:21 +0100, Jan Kiszka wrote:
> What I (think to) understand is that a low-level drivers call
> ieee80211_stop_queue() if they run out of buffers. That flips a
> per-queue bit (IEEE80211_LINK_STATE_XOFF), prevents that any further
> frame is passed to the low-level TX routin
On Wed, Jan 03, 2007 at 05:33:57PM +0100, KOVACS Krisztian ([EMAIL PROTECTED])
wrote:
> The following set of patches implement transparent proxying support
> loosely modeled on the Linux 2.2 transparent proxying functionality.
>
> In the last few years we've been maintaining a set of patches
> im
Jarek Poplawski wrote:
On Wed, Jan 03, 2007 at 09:07:11AM +0100, Jarek Poplawski wrote:
On Tue, Jan 02, 2007 at 03:35:39PM -0800, David Stevens wrote:
I've looked at this a little too -- it'd be nice to know who holds
the write lock.
If you mean mc_list_lock - probably nobody -
ip_route_output() contains a check to make sure that no flows with
non-local source IP addresses are routed. Unfortunately this check
makes it completely impossible to use non-local bound sockets as no
outbound packets will make through the stack.
This patch moves the interface lookup to the multi
TCP input code path looks up the TCP socket hash tables to find a
socket matching the incoming packet. However, as iptable_tproxy does
socket lookups early the skb may already have the appropriate
reference attached, in that case we steal that reference instead of
doing the lookup.
Signed-off-by:
We would like to be able to match on whether or not a given packet has
been diverted by tproxy. To make this possible we need a flag in
sk_buff.
Signed-off-by: KOVACS Krisztian <[EMAIL PROTECTED]>
---
include/linux/skbuff.h |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --gi
UDP input code path looks up the UDP socket hash tables to find a
socket matching the incoming packet. However, as iptable_tproxy does
socket lookups early the skb may already have the appropriate
reference attached, in that case we steal that reference instead of
doing the lookup.
Signed-off-by:
Current TCP code relies on the local port of the listening socket
being the same as the destination address of the incoming
connection. Port redirection used by many transparent proxying
techniques obviously breaks this, so we have to store the original
destination port address.
This patch extends
The following set of patches implement transparent proxying support
loosely modeled on the Linux 2.2 transparent proxying functionality.
In the last few years we've been maintaining a set of patches
implementing Netfilter NAT to provide similar functionality. However,
as time passed, more and more
The iptables tproxy table registers a new hook on PRE_ROUTING and for
each incoming TCP/UDP packet performs as follows:
1. Does a TCP/UDP socket hash lookup to decide whether or not the packet
is sent to a non-local bound socket. If a matching socket is found
and the socket has the IP_FREEBI
Implements an iptables module which matches packets which have the
tproxy flag set, that is, packets diverted in the tproxy table.
Signed-off-by: KOVACS Krisztian <[EMAIL PROTECTED]>
---
net/netfilter/Kconfig |9 +
net/netfilter/Makefile|1 +
net/netfilter/xt_tproxy.c | 77
The TPROXY target implements redirection of non-local TCP/UDP traffic
to local sockets. It is simply a wrapper around functionality exported
from iptable_tproxy.
Signed-off-by: KOVACS Krisztian <[EMAIL PROTECTED]>
---
include/linux/netfilter_ipv4/ipt_TPROXY.h |9 +++
net/ipv4/netfilter/Kcon
The input path for non-local bound sockets requires diverting certain
packets locally, even if their destination IP address is not
considered local. We achieve this by assigning a specially crafted dst
entry to these skbs, and optionally also attaching a socket to the skb
so that the upper layer co
The iptables tproxy code has to be able to do UDP socket hash lookups,
so we have to provide an exported lookup function for this purpose.
Signed-off-by: KOVACS Krisztian <[EMAIL PROTECTED]>
---
include/net/udp.h |4
net/ipv4/udp.c|8
2 files changed, 12 insertions(+),
Jarek Poplawski wrote:
On Tue, Jan 02, 2007 at 03:32:01PM +, Sid Boyce wrote:
Jarek Poplawski wrote:
...
If you could send full ifconfig, route -n (or ip route
if you use additional tables) and tcpdump (all packets)
>from both boxes while pinging each other and a few words
how it is conn
> > > > No, it won't need 2 transitions - just an extra function call,
> > > > so it won't hurt performance - it would improve performance.
> > > >
> > > > ib_uverbs_req_notify_cq would call
> > > >
> > > > ib_uverbs_req_notify_cq()
> > > > {
> > > > ib_set
> > > I've run this code with mthca and didn't notice any performance
> > > degradation, but I wasn't specifically measuring cq_poll overhead in a
> > > tight loop...
> >
> > We were speaking about ib_req_notify_cq here, actually, not cq poll.
> > So what was tested?
> >
>
> Sorry, I meant req_n
On Wed, 2007-01-03 at 17:00 +0200, Michael S. Tsirkin wrote:
> > >
> > > No, it won't need 2 transitions - just an extra function call,
> > > so it won't hurt performance - it would improve performance.
> > >
> > > ib_uverbs_req_notify_cq would call
> > >
> > > ib_uverbs_req_notify_cq()
> > >
On Wed, 2007-01-03 at 17:02 +0200, Michael S. Tsirkin wrote:
> > I've run this code with mthca and didn't notice any performance
> > degradation, but I wasn't specifically measuring cq_poll overhead in a
> > tight loop...
>
> We were speaking about ib_req_notify_cq here, actually, not cq poll.
> S
> I've run this code with mthca and didn't notice any performance
> degradation, but I wasn't specifically measuring cq_poll overhead in a
> tight loop...
We were speaking about ib_req_notify_cq here, actually, not cq poll.
So what was tested?
--
MST
-
To unsubscribe from this list: send the lin
> >
> > No, it won't need 2 transitions - just an extra function call,
> > so it won't hurt performance - it would improve performance.
> >
> > ib_uverbs_req_notify_cq would call
> >
> > ib_uverbs_req_notify_cq()
> > {
> > ib_set_cq_udata(cq, udata)
> >
> > >
> > > It seems all Chelsio needs is to pass in a consumer index - so, how about
> > > a new
> > > entry point? Something like void set_cq_udata(struct ib_cq *cq, struct
> > > ib_udata *udata)?
> > >
> >
> > Adding a new entry point would hurt chelsio's user mode performance if
> > if the
> > > @@ -1373,7 +1374,7 @@ int ib_peek_cq(struct ib_cq *cq, int wc_
> > > static inline int ib_req_notify_cq(struct ib_cq *cq,
> > > enum ib_cq_notify cq_notify)
> > > {
> > > - return cq->device->req_notify_cq(cq, cq_notify);
> > > + return cq->device->req_notify_cq
> > @@ -1373,7 +1374,7 @@ int ib_peek_cq(struct ib_cq *cq, int wc_
> > static inline int ib_req_notify_cq(struct ib_cq *cq,
> >enum ib_cq_notify cq_notify)
> > {
> > - return cq->device->req_notify_cq(cq, cq_notify);
> > + return cq->device->req_notify_cq(cq, c
On Tue, Jan 02, 2007 at 12:38:39AM -0800, David Miller wrote:
> From: Horms <[EMAIL PROTECTED]>
> Date: Mon, 18 Dec 2006 12:11:11 +0900
>
> > I guess that this code used to be more complex, but replacing
> > the goto with a while seems to make things a bit more readable.
> > Or in other words, two
Hi all, I need your advice, please.
Situation:
I have two ppc processors with their SMC2 ports connected to each
other port. Saying 'y' to SMC2 support on kernel 2.4, I can "echo foo
/dev/ttyS1" in one processor while "cat /dev/ttyS1" on the other
and the "foo" text appears.
Question:
I want t
On Tue, Jan 02, 2007 at 03:32:01PM +, Sid Boyce wrote:
> Jarek Poplawski wrote:
...
> >If you could send full ifconfig, route -n (or ip route
> >if you use additional tables) and tcpdump (all packets)
> >from both boxes while pinging each other and a few words
> >how it is connected (other card
Add checksum default defines for mobility header(MH) which
goes through raw socket. As the result kernel's behavior is
to handle MH checksum as default.
This patch also removes verifying inbound MH checksum at
mip6_mh_filter() since it did not consider user specified
checksum offset and was redund
Add checksum default defines for mobility header(MH) which
goes through raw socket. As the result kernel's behavior is
to handle MH checksum as default.
This patch also removes verifying inbound MH checksum at
mip6_mh_filter() since it did not consider user specified
checksum offset and was redund
include/linux/if_tunnel.h is broken for user application
because it was changed to use __be32 which is required
to include linux/types.h in advance but didn't.
(This issue is found when building MIPL2 daemon. We are not sure this
is the last header to be fixed about __be32.)
Signed-off-by: Masahi
Adrian Bunk wrote:
> This patch contains the scheduled removal of the eepro100 driver.
>
I'm sorry to disturb the schedule, but I'm not sure right now if this
pending issue of the e100 was meanwhile solved or declared a non-issue:
http://lkml.org/lkml/2006/9/8/105
Auke, can you confirm that it
Hi Herbert,
| >> While looking at DCCP sequence numbers, I stumbled over a problem with
| >> the following definition of before in tcp.h:
| >>
| >> static inline int before(__u32 seq1, __u32 seq2)
| >> {
| >> return (__s32)(seq1-seq2) < 0;
| >> }
| >>
| >> Problem: This definit
On Wed, Jan 03, 2007 at 09:07:11AM +0100, Jarek Poplawski wrote:
> On Tue, Jan 02, 2007 at 03:35:39PM -0800, David Stevens wrote:
> > I've looked at this a little too -- it'd be nice to know who holds
> > the write lock.
>
> If you mean mc_list_lock - probably nobody - it's
> not initialized (so t
Hi Dave,
first of all - I take my hat off to such astuteness in the light of a mailing
list with an average of 100 postings per day and a massive throughput of patch
submissions. It is clearly awesome to be able to relate individual changes
in light of such a massive flood of patches.
However, I
On Tue, Jan 02, 2007 at 03:35:39PM -0800, David Stevens wrote:
> I've looked at this a little too -- it'd be nice to know who holds
> the write lock.
If you mean mc_list_lock - probably nobody - it's
not initialized (so the timers) for this in_device
and rtnl mutex is preempted by irq.
Actually I
97 matches
Mail list logo
