Yevgeny Petrilin wrote:
Tried to deactivate rx ring that wasn't activated,
used wrong index.
Signed-off-by: Yevgeny Petrilin [EMAIL PROTECTED]
---
drivers/net/mlx4/en_netdev.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/mlx4/en_netdev.c
Yevgeny Petrilin wrote:
Before the change the driver reported the same pause parameters
for all the ports, even only one of them was modified.
Signed-off-by: Yevgeny Petrilin [EMAIL PROTECTED]
---
drivers/net/mlx4/en_netdev.c |8
drivers/net/mlx4/en_params.c | 30
Roland Dreier wrote:
Roland, OK for me to put merge this via net-next (the standard avenue
for drivers/net patches during -rc)?
Actually please let me review this and merge it through my tree, since
it has a bigger impact on the IB side of mlx4.
It seems most appropriate to get an
Roland Dreier wrote:
In general I think I have a bigger chance of merging more mlx4_core
stuff through my tree, so it will probably be smoother in terms of
conflicts etc. if I carry this patch.
Fine by me...
Jeff
___
general mailing list
Yevgeny Petrilin wrote:
The driver now creates a completion EQ for every cpu.
While allocating CQ a ULP asks a completion vector number
it wants the CQ to be attached to. The number of completion
vectors is advertised via ib_device.num_comp_vectors
Signed-off-by: Yevgeny Petrilin [EMAIL
Yevgeny Petrilin wrote:
Signed-off-by: Yevgeny Petrilin [EMAIL PROTECTED]
---
drivers/net/mlx4/fw.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/mlx4/fw.c b/drivers/net/mlx4/fw.c
index be09fdb..cee199c 100644
--- a/drivers/net/mlx4/fw.c
+++
Huang Weiyi wrote:
Removed duplicated #include linux/cpumask.h in
drivers/net/mlx4/en_main.c.
Signed-off-by: Huang Weiyi [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
diff --git a/drivers/net/mlx4/en_main.c b/drivers/net/mlx4/en_main.c
index 1b0eebf..4b9794e 100644
---
Ramachandra K wrote:
If you are referring to IP address configuration etc, users can configure
the interfaces by setting up ifcfg files and the interfaces are automatically
configured when they are registered.
That makes a lot of assumptions about the Linux distribution and
userspace setup,
Ingo Molnar wrote:
2) you might know that Deja-Vu moment when you look at a new patch that
has been submitted to lkml and you have a strange, weird feeling
that there's something wrong about the patch.
It's totally subconscious, and you take a closer look and a few
seconds
Greg KH wrote:
On Fri, Feb 22, 2008 at 01:33:03AM +0300, Alexey Dobriyan wrote:
Speaking of driver, could authors please comment all those barrier()
calls and remove trailing return; at the end of void functions.
Why don't you make a patch to checkpatch.pl for those types of things?
:)
Krzysztof Halasa wrote:
Linus Torvalds [EMAIL PROTECTED] writes:
I'm personally of the opinion that a lot of checkpatch fixes are
anything but. That mainly concerns fixing overlong lines
Perhaps we should increase line length limit, 132 should be fine.
I think checkpatch is useful, but
Krzysztof Halasa wrote:
Jeff Garzik [EMAIL PROTECTED] writes:
If a driver is full of lines of length 80, that's a problem.
I'm not sure.
We all have more than 80-chars wide displays for years, don't we? The
Every time this discussion comes up, people point out that it remains
highly
Linus Torvalds wrote:
Oh, and obviously, the NAPI changes may well have resulted in a merge that
had no actual *conflicts* in it, but whether the end result works or not
(and whether any IB drivers need updating due to the NAPI changes), I
cannot tell. I've pushed out my tree, so people who
David Miller wrote:
From: Krishna Kumar2 [EMAIL PROTECTED]
Date: Tue, 9 Oct 2007 16:51:14 +0530
David Miller [EMAIL PROTECTED] wrote on 10/09/2007 04:32:55 PM:
Ignore LLTX, it sucks, it was a big mistake, and we will get rid of
it.
Great, this will make life easy. Any idea how long that
Herbert Xu wrote:
On Tue, Oct 09, 2007 at 08:44:25AM -0400, Jeff Garzik wrote:
David Miller wrote:
I can just threaten to do them all and that should get the driver
maintainers going :-)
What, like this? :)
Awsome :)
Note my patch is just to get the maintainers going. :) I'm not going
Waskiewicz Jr, Peter P wrote:
IMO the net driver really should provide a hint as to what it wants.
8139cp and tg3 would probably prefer multiple TX queue
behavior to match silicon behavior -- strict prio.
If I understand what you just said, I disagree. If your hardware is
running strict
David Miller wrote:
From: Roland Dreier [EMAIL PROTECTED]
Date: Tue, 09 Oct 2007 15:46:13 -0700
The conversion to use netdevice internal stats left an unused variable
in ipoib_neigh_free(), since there's no longer any reason to get
netdev_priv() in order to increment dropped packets. Delete
Roland Dreier wrote:
The conversion to use netdevice internal stats left an unused variable
in ipoib_neigh_free(), since there's no longer any reason to get
netdev_priv() in order to increment dropped packets. Delete the
unused priv variable.
Signed-off-by: Roland Dreier [EMAIL PROTECTED]
---
jamal wrote:
On Sun, 2007-07-10 at 21:51 -0700, David Miller wrote:
For these high performance 10Gbit cards it's a load balancing
function, really, as all of the transmit queues go out to the same
physical port so you could:
1) Load balance on CPU number.
2) Load balance on flow
3) Load
jamal wrote:
Ok, so the concurency aspect is what worries me. What i am saying is
that sooner or later you have to serialize (which is anti-concurency)
For example, consider CPU0 running a high prio queue and CPU1 running
the low prio queue of the same netdevice.
Assume CPU0 is getting a lot of
jamal wrote:
The challenge to deal with is that netdevices, filters, the queues and
scheduler are closely inter-twined. So it is not just the scheduling
region and QDISC_RUNNING. For example, lets pick just the filters
because they are simple to see: You need to attach them to something -
David Miller wrote:
From: Jeff Garzik [EMAIL PROTECTED]
Date: Mon, 08 Oct 2007 10:22:28 -0400
In terms of overall parallelization, both for TX as well as RX, my gut
feeling is that we want to move towards an MSI-X, multi-core friendly
model where packets are LIKELY to be sent and received
David Miller wrote:
1) A library for transmit load balancing functions, with an interface
that can be made visible to userspace. I can write this and test
it on real multiqueue hardware.
The whole purpose of this library is to set skb-queue_mapping
based upon the load balancing
Moni Shoua wrote:
Jay Vosburgh wrote:
ACK patches 3 - 9.
Roland, are you comfortable with the IB changes in patches 1 and 2?
Jeff, when Roland acks patches 1 and 2, please apply all 9.
-J
Hi Jeff,
Roland acked the IPoIB patches. If you haven't done so already can
jamal wrote:
If the intel folks will accept the patch i'd really like to kill
the e1000 LLTX interface.
If I understood DaveM correctly, it is sounding like we want to
deprecate all of use LLTX on real hardware? If so, several such
projects might be considered, as well as possibly
jamal wrote:
More patches to follow - i didnt want to overload people by dumping
too many patches. Most of these patches below are ready to go; some are
need some testing and others need a little porting from an earlier
kernel:
- tg3 driver (tested and works well, but dont want to send
- tun
Please remove me from the CC list.
I get this via netdev, and not having said a single thing in the thread,
I don't feel the need to be CC'd on every email.
The CC list is pretty massive as it is, anyway.
Jeff
___
general mailing list
Steve Wise wrote:
I was about to post v2 of my patch to avoid port space collisions with
the native stack. Can we get that 2.6.24? It is high priority IMO.
I've tried to solicit review on it, but I think folks are reluctant... ;-)
Well, if it involves /sharing/ port space with the native
Steve Wise wrote:
Jeff Garzik wrote:
Steve Wise wrote:
I was about to post v2 of my patch to avoid port space collisions
with the native stack. Can we get that 2.6.24? It is high priority
IMO. I've tried to solicit review on it, but I think folks are
reluctant... ;-)
Well, if it involves
Steve Wise wrote:
David Miller wrote:
From: Sean Hefty [EMAIL PROTECTED]
Date: Thu, 09 Aug 2007 14:40:16 -0700
Steve Wise wrote:
Any more comments?
Does anyone have ideas on how to reserve the port space without using
a struct socket?
How about we just remove the RDMA stack altogether?
30 matches
Mail list logo
