* Re: e1000 driver and samba
From: L F @ 2007-09-21 14:08 UTC (permalink / raw)
To: Bill Fink; +Cc: netdev
In-Reply-To: <20070919225105.1e80e91d.billfink@mindspring.com>
On 9/19/07, Bill Fink <billfink@mindspring.com> wrote:
> Just my personal opinion, but unless you want to do more testing,
> since you now seem to have a working setup, I would tend to leave
> it the way it is.
Quite sensible, yes. Performance even seems to be good - I am getting
40-40MBps reads and 24-26MBps writes - so it'll stay the way it is.
> By any chance did you happen to power cycle some equipment in this
> process that you didn't previously power cycle during earlier testing
> and debugging? If so, perhaps that hardware had somehow gotten into
> a funky state, and the power cycling might have cleared it up.
Not that I am aware of: one of the first things that I did - and
repeated basically every step of the way - was to powercycle the two
switches, following the same line of reasoning you did. The clients
were turned off every night and turned back on every morning and the
WAN Comcast CPE wasn't touched for the duration. The only thing that
did change is that in an impetus of efficiency or perhaps desperation
I changed that cable too (to CAT6, 3' long), but I can't imagine that
would affect the LAN side of operations.
Thanks again - to everyone - for the help. I am still puzzled, but at
least I am puzzled with a consistent situation.
To Mr. Romieu: the patch you provided seems to work, in that 'regular'
loads don't trip samba up. I have to check the CRCs, though.
> -Bill
Luigi Fabio
^ permalink raw reply
* Re: e1000 driver and samba
From: L F @ 2007-09-21 14:13 UTC (permalink / raw)
To: Bruce Cole; +Cc: netdev
In-Reply-To: <46F302A8.7040008@gmail.com>
On 9/20/07, Bruce Cole <bacole@gmail.com> wrote:
> Yes, that *was* the common recommendation. But recently I narrowed down the
> realtek performance problem most commonly seen with samba (but also applicable
> to other TCP applications), and I also narrowed down the fix as well.
>
> The current fix involves re-kicking the TX queue after it becomes stuck.
> Apparently it becomes stuck due to a contention problem between the driver and
> controller. I suspect the root problem is the driver isn't properly locking
> the TX queue. It might be worth checking if the queue locking problem exists
> in other net drivers as well.
Aha. This doesn't seem to be in mr. Romieu's patch above: should it go
in on top of that?
I ask because with the forementioned patch the newer integrated NICs
seem to be recognised correctly and preliminary testing shows no
disconnect issues, but performance is nothing to write home about (one
of these days I'll get into a rant about samba speed vs. ftp speed,
but this is not the time nor place).
> Reference:
> http://www.spinics.net/lists/netdev/msg40384.html
> Bruce Cole
LF
^ permalink raw reply
* Re: change the way e1000 is handling short VLAN frames
From: Francesco Fondelli @ 2007-09-21 14:27 UTC (permalink / raw)
To: hadi; +Cc: Emil Micek, auke-jan.h.kok@intel.com, netdev mailing list,
Ben Greear
In-Reply-To: <1190382366.4231.13.camel@localhost>
On 9/21/07, jamal <hadi@cyberus.ca> wrote:
> Hope that makes sense.
[cut]
> cheers,
> jamal
Hi all,
as far as I understand ieee docs both 64 and 68
approaches are fine...
--- Std 802.1Q-2005, 6.5.1 ---
On receipt of an M_UNITDATA.request primitive that
represents a tagged frame, the implementation is
permitted to adopt either of the following approaches
with regard to the operation of Transmit Data
Encapsulation for frames whose length would, using the
procedure as described, be less than 68 octets:
a) Use the procedure as described in 6.5.1 of IEEE
Std 802.1D. This procedure can result in
tagged frames of less than 68 octets (but at least 64 octets)
being transmitted; or
b) Include additional octets before the FCS field in order
for the transmitted frame length for such frames to be
68 octets. This procedure results in a minimum tagged
frame length of 68 octets.
When a tagged frame of less than 68 octets in length
is received on a CSMA/CD LAN segment, and is forwarded
as an untagged frame, the provisions of 6.5.1 of
IEEE Std 802.1D, result in additional octets
being included before the FCS field on transmission
in order that the transmitted frame length meets the
minimum frame size requirements of 3.2.7 in IEEE Std 802.3.
------------------------------
and
--- Std 802.1Q-2005, C.4.4.1 ---
When tagged frames are transmitted by a Bridge on an
IEEE Std 802.3 MAC, there are two permissible
approaches (7.2), as follows:
a) Keep the minimum frame size generated by the Bridge
equal to 64 octets. This implies that the
number of pad octets in a received untagged IEEE Std 802.3
frame would be reduced by up to 4 octets when that frame
was tagged;
b) Adopt a minimum tagged frame length of 68 octets.
This implies that the number of pad octets in a
received untagged IEEE Std 802.3 frame would not be adjusted
when tagging such frames; equally, if subsequently untagged,
no pad adjustment would be necessary before transmission on
IEEE 802.3/Ethernet.
------------------------------
might this problem be solved using a configurable parameter?
(default=68)
my 0.02 euro
Ciao
FF
^ permalink raw reply
* Re: [RFC PATCH] 2.6.22.6 netfilter: sk_setup_caps in ip_make_route_harder
From: Patrick McHardy @ 2007-09-21 14:57 UTC (permalink / raw)
To: lepton; +Cc: netfilter-devel, netdev
In-Reply-To: <20070921140720.GA10419@router.lepton.home>
lepton wrote:
> My situation is:
> The default route device is a e1000 network card that can do TSO.
> So the tcp stack will try send big skb to netfilter frame work.
> But after rerouting, the packtes will go out from a device that
> can not do TSO. the packet is just get dropped..
>
> I thinks if we can't get a way to tell tcp stack the sk_route_caps of
> the real out device, we can just disable all things for safety.
As you already noticed yourself (in private email), this is
handled properly in current kernels.
^ permalink raw reply
* [PATCH] note that NETIF_F_LLTX is deprecated (was: [kvm-devel][PATCH 3/6] virtio net driver)
From: Christian Borntraeger @ 2007-09-21 14:59 UTC (permalink / raw)
To: Herbert Xu; +Cc: Jeff Garzik, netdev, David Miller
In-Reply-To: <20070921140833.GA12242@gondor.apana.org.au>
Am Freitag, 21. September 2007 schrieb Herbert Xu:
> Please don't use LLTX in new drivers. We're trying to get rid
> of it since it's
>
> 1) unnecessary;
> 2) causes problems with AF_PACKET seeing things twice.
I suggest to document that LLTX is deprecated.
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
---
Documentation/networking/netdevices.txt | 3 ++-
include/linux/netdevice.h | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
Index: linux-2.6/include/linux/netdevice.h
===================================================================
--- linux-2.6.orig/include/linux/netdevice.h
+++ linux-2.6/include/linux/netdevice.h
@@ -339,7 +339,8 @@ struct net_device
#define NETIF_F_HW_VLAN_FILTER 512 /* Receive filtering on VLAN */
#define NETIF_F_VLAN_CHALLENGED 1024 /* Device cannot handle VLAN packets */
#define NETIF_F_GSO 2048 /* Enable software GSO. */
-#define NETIF_F_LLTX 4096 /* LockLess TX */
+#define NETIF_F_LLTX 4096 /* LockLess TX - deprecated. Please */
+ /* do not use LLTX in new drivers */
#define NETIF_F_MULTI_QUEUE 16384 /* Has multiple TX/RX queues */
/* Segmentation offload features */
Index: linux-2.6/Documentation/networking/netdevices.txt
===================================================================
--- linux-2.6.orig/Documentation/networking/netdevices.txt
+++ linux-2.6/Documentation/networking/netdevices.txt
@@ -73,7 +73,8 @@ dev->hard_start_xmit:
has to lock by itself when needed. It is recommended to use a try lock
for this and return NETDEV_TX_LOCKED when the spin lock fails.
The locking there should also properly protect against
- set_multicast_list.
+ set_multicast_list. Note that the use of NETIF_F_LLTX is deprecated.
+ Dont use it for new drivers.
Context: Process with BHs disabled or BH (timer),
will be called with interrupts disabled by netconsole.
^ permalink raw reply
* [ofa-general] Re: [PATCH v2] iw_cxgb3: Support "iwarp-only" interfaces to avoid 4-tuple conflicts.
From: Steve Wise @ 2007-09-21 15:10 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: netdev, rdreier, general, linux-kernel
In-Reply-To: <20070919105612.GA31158@2ka.mipt.ru>
Evgeniy Polyakov wrote:
> Hi Steve.
>
> On Mon, Sep 17, 2007 at 10:25:04AM -0500, Steve Wise (swise@opengridcomputing.com) wrote:
>>> Does creating the whole new netdevice is a too big overhead, or is it
>>> considered bad idea?
>> I think its too big overhead, and pretty invasive on the low level cxgb3
>> driver. I think having a device in the 'ifconfig -a' after iw_cxgb3 is
>> loaded and devices discovered would be a good thing for the admin. This
>> is the angle Roland suggested. I'm just not sure how to implement it.
>>
>> But if someone could explain how I might create this full netdevice as a
>> pseudo device on top of the real one, maybe I could implement it.
>>
>> Note that non TCP traffic still needs to utilize this interface for ND
>> to work properly with the RDMA core.
>
> Just a though - what about allowing secondary addresses with the same
> address as main one? I.e. change bit of the core code to allow creating
> aliases with the same address as main device, so that you would be able
> to create ':iw' alias during rdma device initialization?
>
The problem is that on rdma route/address resolution the rdma core CM
uses the routing table to look up which local device to use. So what we
need is separate ip subnets for rdma vs non rdma tcp.
Also, to avoid the original issue of 4-tuple conflicts, the rdma device
_must_ listen on specific local "rdma-only" ip addresses and thus they
must be not the same address as that used for native host tcp traffic.
Steve.
^ permalink raw reply
* Re: change the way e1000 is handling short VLAN frames
From: Ben Greear @ 2007-09-21 15:43 UTC (permalink / raw)
To: hadi; +Cc: Emil Micek, auke-jan.h.kok@intel.com, netdev mailing list
In-Reply-To: <1190382366.4231.13.camel@localhost>
jamal wrote:
> On Fri, 2007-21-09 at 09:37 -0400, jamal wrote:
>
>> On Fri, 2007-21-09 at 14:50 +0200, Emil Micek wrote:
>>
>>> On Fri, 2007-09-21 at 07:59 -0400, jamal wrote:
>>>
>>>> Which would make it a bug. AFAIK, the minimum VLAN tagged packet going
>>>> out is 68 bytes.
>>>>
>>> Are you sure about this?
>>>
>> This is what i have always seen.
>>
>
> If the first email caused confusion - so will this ;->
> I have never used e1000 for vlan tagging. My view is that if it emits
> (instead of 68B) 64B packets with tags then it is buggy and needs to be
> fixed. Hope that makes sense.
>
I just re-read the spec, and a bridge *may* pad up to 68, but it is not
required.
On page 166, it says equipment must be able to handle 64 byte minimums.
See page 22 (section 7.2) of this document:
http://standards.ieee.org/getieee802/download/802.1Q-1998.pdf
Also, page 63, 165, 166
Thanks,
Ben
>
> cheers,
> jamal
>
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: SFQ qdisc crashes with limit of 2 packets
From: Alexey Kuznetsov @ 2007-09-21 15:55 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Chuck Ebbert, Netdev
In-Reply-To: <46F11F46.8060108@trash.net>
Hello!
Remove artificial limitation for sfq queue limit.
This is followup to Patrick's patch. A little optimization to enqueue
routine allows to remove artificial limitation on queue length.
Plus, testing showed that hash function used by SFQ is too bad or even worse.
It does not even sweep the whole range of hash values.
Switched to Jenkins' hash.
Signed-off-by: Alexey Kuznetsov <kaber@ms2.inr.ac.ru>
diff --git a/net/sched/sch_sfq.c b/net/sched/sch_sfq.c
index 3a23e30..b542c87 100644
--- a/net/sched/sch_sfq.c
+++ b/net/sched/sch_sfq.c
@@ -19,6 +19,7 @@
#include <linux/init.h>
#include <linux/ipv6.h>
#include <linux/skbuff.h>
+#include <linux/jhash.h>
#include <net/ip.h>
#include <net/netlink.h>
#include <net/pkt_sched.h>
@@ -95,7 +96,7 @@ struct sfq_sched_data
/* Variables */
struct timer_list perturb_timer;
- int perturbation;
+ u32 perturbation;
sfq_index tail; /* Index of current slot in round */
sfq_index max_depth; /* Maximal depth */
@@ -109,12 +110,7 @@ struct sfq_sched_data
static __inline__ unsigned sfq_fold_hash(struct sfq_sched_data *q, u32 h, u32 h1)
{
- int pert = q->perturbation;
-
- /* Have we any rotation primitives? If not, WHY? */
- h ^= (h1<<pert) ^ (h1>>(0x1F - pert));
- h ^= h>>10;
- return h & 0x3FF;
+ return jhash_2words(h, h1, q->perturbation) & (SFQ_HASH_DIVISOR - 1);
}
static unsigned sfq_hash(struct sfq_sched_data *q, struct sk_buff *skb)
@@ -256,6 +252,13 @@ sfq_enqueue(struct sk_buff *skb, struct Qdisc* sch)
q->ht[hash] = x = q->dep[SFQ_DEPTH].next;
q->hash[x] = hash;
}
+ /* If selected queue has length q->limit, this means that
+ * all another queues are empty and that we do simple tail drop,
+ * i.e. drop _this_ packet.
+ */
+ if (q->qs[x].qlen >= q->limit)
+ return qdisc_drop(skb, sch);
+
sch->qstats.backlog += skb->len;
__skb_queue_tail(&q->qs[x], skb);
sfq_inc(q, x);
@@ -294,6 +297,19 @@ sfq_requeue(struct sk_buff *skb, struct Qdisc* sch)
}
sch->qstats.backlog += skb->len;
__skb_queue_head(&q->qs[x], skb);
+ /* If selected queue has length q->limit+1, this means that
+ * all another queues are empty and we do simple tail drop.
+ * This packet is still requeued at head of queue, tail packet
+ * is dropped.
+ */
+ if (q->qs[x].qlen > q->limit) {
+ skb = q->qs[x].prev;
+ __skb_unlink(skb, &q->qs[x]);
+ sch->qstats.drops++;
+ sch->qstats.backlog -= skb->len;
+ kfree_skb(skb);
+ return NET_XMIT_CN;
+ }
sfq_inc(q, x);
if (q->qs[x].qlen == 1) { /* The flow is new */
if (q->tail == SFQ_DEPTH) { /* It is the first flow */
@@ -370,12 +386,10 @@ static void sfq_perturbation(unsigned long arg)
struct Qdisc *sch = (struct Qdisc*)arg;
struct sfq_sched_data *q = qdisc_priv(sch);
- q->perturbation = net_random()&0x1F;
+ get_random_bytes(&q->perturbation, 4);
- if (q->perturb_period) {
- q->perturb_timer.expires = jiffies + q->perturb_period;
- add_timer(&q->perturb_timer);
- }
+ if (q->perturb_period)
+ mod_timer(&q->perturb_timer, jiffies + q->perturb_period);
}
static int sfq_change(struct Qdisc *sch, struct rtattr *opt)
@@ -391,7 +405,7 @@ static int sfq_change(struct Qdisc *sch, struct rtattr *opt)
q->quantum = ctl->quantum ? : psched_mtu(sch->dev);
q->perturb_period = ctl->perturb_period*HZ;
if (ctl->limit)
- q->limit = min_t(u32, ctl->limit, SFQ_DEPTH - 2);
+ q->limit = min_t(u32, ctl->limit, SFQ_DEPTH - 1);
qlen = sch->q.qlen;
while (sch->q.qlen > q->limit)
@@ -400,8 +414,8 @@ static int sfq_change(struct Qdisc *sch, struct rtattr *opt)
del_timer(&q->perturb_timer);
if (q->perturb_period) {
- q->perturb_timer.expires = jiffies + q->perturb_period;
- add_timer(&q->perturb_timer);
+ mod_timer(&q->perturb_timer, jiffies + q->perturb_period);
+ get_random_bytes(&q->perturbation, 4);
}
sch_tree_unlock(sch);
return 0;
@@ -423,12 +437,13 @@ static int sfq_init(struct Qdisc *sch, struct rtattr *opt)
q->dep[i+SFQ_DEPTH].next = i+SFQ_DEPTH;
q->dep[i+SFQ_DEPTH].prev = i+SFQ_DEPTH;
}
- q->limit = SFQ_DEPTH - 2;
+ q->limit = SFQ_DEPTH - 1;
q->max_depth = 0;
q->tail = SFQ_DEPTH;
if (opt == NULL) {
q->quantum = psched_mtu(sch->dev);
q->perturb_period = 0;
+ get_random_bytes(&q->perturbation, 4);
} else {
int err = sfq_change(sch, opt);
if (err)
^ permalink raw reply related
* want same order in /sys/class/net/eth as /sys/bus/pci/devices
From: John Reiser @ 2007-09-21 15:59 UTC (permalink / raw)
To: netdev
I'd like to see the same order of devices in /sys/class/net/eth*
as in /sys/bus/pci/devices. This would make administration easier.
On Fedora 8 tests, the order I see is reversed:
http://bugzilla.redhat.com/show_bug.cgi?id=291431
Perhaps the reversal is a result of the alias order listed in
/etc/modprobe.conf. But the alias order was obtained from some
source. Was the first reversal due to a user-space program
(such as the anaconda installer), or due to something within
the kernel?
--
John Reiser, jreiser@BitWagon.com
^ permalink raw reply
* Re: [PATCH 1/2] bnx2: factor out gzip unpacker
From: David Miller @ 2007-09-21 16:14 UTC (permalink / raw)
To: vda.linux; +Cc: jeff, mchan, linux-kernel, netdev
In-Reply-To: <200709211201.24475.vda.linux@googlemail.com>
From: Denys Vlasenko <vda.linux@googlemail.com>
Date: Fri, 21 Sep 2007 12:01:24 +0100
> Hi Jeff,
BNX2 and TG3 patches goes through Michael Chan and myself,
and I usually merge them in instead of Jeff.
^ permalink raw reply
* Re: net-2.6.24 - build failure
From: Michael Buesch @ 2007-09-21 16:18 UTC (permalink / raw)
To: David Miller; +Cc: joe, netdev, linux-wireless
In-Reply-To: <20070919.151712.66176476.davem@davemloft.net>
On Thursday 20 September 2007 00:17:12 David Miller wrote:
> From: Joe Perches <joe@perches.com>
> Date: Wed, 19 Sep 2007 14:53:22 -0700
>
> > drivers/net/wireless/b43legacy/built-in.o: In function `tsf_read_file':
> > drivers/net/wireless/b43legacy/debugfs.c:80: multiple definition of `tsf_read_file'
>
> Can one of the wireless folks fix b43legacy to not use the same
> global variable and function names as the b43 driver?
Fixes are already submitted.
This was only an accident (forgot static).
--
Greetings Michael.
^ permalink raw reply
* [PATCH] e1000e: Do not allow requeue of freed skb
From: Auke Kok @ 2007-09-21 16:41 UTC (permalink / raw)
To: jeff, davem; +Cc: hadi, krkumar2, netdev
From: Krishna Kumar <krkumar2@in.ibm.com>
Returning BUSY will make qdisc_restart enqueue the skb which was already
freed. The bad skb was correctly freed and we should return NETDEV_TX_OK.
First spotted by Jeff Garzik on 08/13/07.
Signed-off-by: Krishna Kumar <krkumar2@in.ibm.com>
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
---
drivers/net/e1000e/netdev.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index 372da46..03f7472 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -3537,7 +3537,7 @@ static int e1000_xmit_frame(struct sk_buff *skb, struct net_device *netdev)
/* handle pci_map_single() error in e1000_tx_map */
dev_kfree_skb_any(skb);
spin_unlock_irqrestore(&adapter->tx_queue_lock, irq_flags);
- return NETDEV_TX_BUSY;
+ return NETDEV_TX_OK;
}
e1000_tx_queue(adapter, tx_flags, count);
^ permalink raw reply related
* Re: [PATCH 2/7] CAN: Add PF_CAN core module
From: Joe Perches @ 2007-09-21 16:58 UTC (permalink / raw)
To: Urs Thuermann
Cc: netdev, David Miller, Patrick McHardy, Thomas Gleixner,
Oliver Hartkopp, Oliver Hartkopp
In-Reply-To: <ygf8x705mrq.fsf@janus.isnogud.escape.de>
On Fri, 2007-09-21 at 12:35 +0200, Urs Thuermann wrote:
> I didn't find a way with gcc-2.95 to make the format
> string a separate macro argument (which I also wanted).
The old 2.x GCC workaround was to use
#define DBG(fmt, arg) printk(fmt , ## arg)
adding a space before the last comma.
> I use "do { ... } while(0)" only for statements, not for expressions.
> But I could have used the && instead of ?: operator. I don't think
> the "do { ... } while(0)" looks nicer or has any other advantage.
It's more linux convention.
It allows the macro to be used in if-else constructs.
> > > void can_debug_cframe(const char *msg, struct can_frame *cf, ...)
> > This prototype looks backwards to me.
> You mean the order or `msg' and `cf'?
Yes, I believe the can_frame* should be the first argument.
> Ah, I didn't know print_hex_dump(). That looks nicer. But as Thomas
> mentioned, we shouldn't convert these functions into macros.
The first print_hex_dump should actually be print_hex_dump_bytes.
I was typing what I hoped was a readable example.
I hope you do convert to functions, but not to inline functions.
cheers, Joe
^ permalink raw reply
* Re: [PATCH 1/2] bnx2: factor out gzip unpacker
From: Denys Vlasenko @ 2007-09-21 17:03 UTC (permalink / raw)
To: David Miller; +Cc: jeff, mchan, linux-kernel, netdev
In-Reply-To: <20070921.091432.74736040.davem@davemloft.net>
On Friday 21 September 2007 17:14, David Miller wrote:
> From: Denys Vlasenko <vda.linux@googlemail.com>
> Date: Fri, 21 Sep 2007 12:01:24 +0100
>
> > Hi Jeff,
>
> BNX2 and TG3 patches goes through Michael Chan and myself,
> and I usually merge them in instead of Jeff.
Didn't know that, sorry.
Do patches look ok to you?
--
vda
^ permalink raw reply
* RE: change the way e1000 is handling short VLAN frames
From: Brandeburg, Jesse @ 2007-09-21 17:05 UTC (permalink / raw)
To: Emil Micek, hadi; +Cc: Kok, Auke-jan H, netdev mailing list
In-Reply-To: <1190379015.3551.57.camel@magi.nadr>
Emil Micek wrote:
> What is the right behaviour according to specification? In iee802.3,
> minFrameSize is 64bytes. I've never seen any document which'd say that
> VLAN frames should be 68 bytes minimum.
e1000 only hardware pads to 64 bytes, but if you use the vlan module and
turn off the hardware assistance of inserting tags, by unsetting
NETIF_F_HW_VLAN_* in netdev->features.
the software insertion sounds like it should work for you at the cost of
higher CPU.
>>> I'd like to change it so it first pads the frame to 64 B and
>>> appends the VLAN tag afterwards, so the resulting VLAN frame would
>>> be 68 bytes minimum.
at least for e1000 this isn't possible in the driver, while still doing
hardware vlan insertion.
Jesse
^ permalink raw reply
* Re: [PATCH 2.6.23-rc6 Resending] NETWORKING : Edge Triggered EPOLLOUT events get missed for TCP sockets
From: Davide Libenzi @ 2007-09-21 17:45 UTC (permalink / raw)
To: Nagendra Tomar; +Cc: netdev, Linux Kernel Mailing List, David Miller
In-Reply-To: <798693.92196.qm@web53705.mail.re2.yahoo.com>
On Thu, 20 Sep 2007, Nagendra Tomar wrote:
> > That's not what POLLOUT means in the Unix meaning. POLLOUT indicates the
> > ability to write, and it is not meant as to signal every time a packet
> > (skb) is sent on the wire (and the buffer released).
>
> Aren't they both the same ? Everytime an incoming ACK frees up a buffer
> from the retransmit queue, the writability condition is freshly asserted,
> much the same way as the readability condition is asserted everytime a
> new data is queued in the socket receive queue (irrespective of
> whether there was data already waiting to be read in the receive queue).
>
> This difference in meaning of POLLOUT only arises in the ET case, which was
> not what traditional Unix poll referred to.
Again, events here are "readability" and "writeability" and the fact that
the lower network layer freed a buffer is not, per se, an event (unless
before, "writeability" was tested and reported as unavailable).
In you case the solution looks pretty simple. Just create appropriately
sized buffers, split the single sendfile into multiple buffer-sized ones,
and recycle the buffer once each of them completes.
- Davide
^ permalink raw reply
* Re: [PATCH 1/2] bnx2: factor out gzip unpacker
From: David Miller @ 2007-09-21 17:49 UTC (permalink / raw)
To: vda.linux; +Cc: jeff, mchan, linux-kernel, netdev
In-Reply-To: <200709211803.55554.vda.linux@googlemail.com>
From: Denys Vlasenko <vda.linux@googlemail.com>
Date: Fri, 21 Sep 2007 18:03:55 +0100
> Do patches look ok to you?
I'm travelling so I haven't looked closely yet :-)
Michael can take a look and I'll try to do so as well
tonight.
^ permalink raw reply
* Re: [PATCH 1/2] bnx2: factor out gzip unpacker
From: Denys Vlasenko @ 2007-09-21 18:05 UTC (permalink / raw)
To: David Miller; +Cc: jeff, mchan, linux-kernel, netdev
In-Reply-To: <20070921.104912.41646795.davem@davemloft.net>
On Friday 21 September 2007 18:49, David Miller wrote:
> From: Denys Vlasenko <vda.linux@googlemail.com>
> Date: Fri, 21 Sep 2007 18:03:55 +0100
>
> > Do patches look ok to you?
>
> I'm travelling so I haven't looked closely yet :-)
>
> Michael can take a look and I'll try to do so as well
> tonight.
Good.
I plan to use gzip compression on following drivers' firmware,
if patches will be accepted:
text data bss dec hex filename
17653 109968 240 127861 1f375 drivers/net/acenic.o
6628 120448 4 127080 1f068 drivers/net/dgrs.o
^^^^^^
--
vda
^ permalink raw reply
* Re: [PATCH 2/7] CAN: Add PF_CAN core module
From: Urs Thuermann @ 2007-09-21 18:01 UTC (permalink / raw)
To: Patrick McHardy
Cc: netdev, David Miller, Thomas Gleixner, Oliver Hartkopp,
Oliver Hartkopp
In-Reply-To: <46F3BD75.6010904@trash.net>
Patrick McHardy <kaber@trash.net> writes:
> You drop the module reference again when leaving this function.
> So sock->ops might contain a stale pointer if the module is
> unloaded after this. You need to either keep the module reference
> while the socket is alive or remove stale references when
> unregistering the protocol.
I don't think that can happen. Before we drop the module reference we
call sk_alloc() which gets another module reference via its cp->prot
argument. If sk_alloc() fails we return with error from can_create()
I assume sock->ops won't be used after that.
urs
^ permalink raw reply
* [updated PATCH] forcedeth: power down phy when interface is down
From: Ed Swierk @ 2007-09-21 18:12 UTC (permalink / raw)
To: Ayaz Abdulla, netdev; +Cc: linux-kernel
In-Reply-To: <46F1D83B.5070100@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 408 bytes --]
On 9/19/07, Ayaz Abdulla <aabdulla@nvidia.com> wrote:
> It seems that you are powering down the phy even if WOL is enabled.
Right; I've updated the patch to skip powering down the phy when wol is enabled.
> Secondly, can you powerdown the phy at the same time you start
> performing autoneg restart?
This seems to work fine with a BCM5461S phy; it would be worth testing
with other phys to be sure.
--Ed
[-- Attachment #2: forcedeth-phy-power-down.patch --]
[-- Type: application/octet-stream, Size: 2264 bytes --]
Bring the physical link down when the interface is down by placing the PHY
in power-down state, unless WOL is enabled. This mirrors the behavior of
other drivers including e1000 and tg3.
Signed-off-by: Ed Swierk <eswierk@arastra.com>
Index: linux-2.6.22.1/drivers/net/forcedeth.c
===================================================================
--- linux-2.6.22.1.orig/drivers/net/forcedeth.c
+++ linux-2.6.22.1/drivers/net/forcedeth.c
@@ -112,6 +112,7 @@
* 0.58: 30 Oct 2006: Added support for sideband management unit.
* 0.59: 30 Oct 2006: Added support for recoverable error.
* 0.60: 20 Jan 2007: Code optimizations for rings, rx & tx data paths, and stats.
+ * 0.61: 21 Sep 2007: Power down phy when interface down and wol disabled.
*
* Known bugs:
* We suspect that on some hardware no TX done interrupts are generated.
@@ -128,7 +129,7 @@
#else
#define DRIVERNAPI
#endif
-#define FORCEDETH_VERSION "0.60"
+#define FORCEDETH_VERSION "0.61"
#define DRV_NAME "forcedeth"
#include <linux/module.h>
@@ -1170,9 +1171,9 @@ static int phy_init(struct net_device *d
/* some phys clear out pause advertisment on reset, set it back */
mii_rw(dev, np->phyaddr, MII_ADVERTISE, reg);
- /* restart auto negotiation */
+ /* restart auto negotiation, power down phy */
mii_control = mii_rw(dev, np->phyaddr, MII_BMCR, MII_READ);
- mii_control |= (BMCR_ANRESTART | BMCR_ANENABLE);
+ mii_control |= (BMCR_ANRESTART | BMCR_ANENABLE | BMCR_PDOWN);
if (mii_rw(dev, np->phyaddr, MII_BMCR, mii_control)) {
return PHY_ERROR;
}
@@ -4694,6 +4695,10 @@ static int nv_open(struct net_device *de
dprintk(KERN_DEBUG "nv_open: begin\n");
+ /* power up phy */
+ mii_rw(dev, np->phyaddr, MII_BMCR,
+ mii_rw(dev, np->phyaddr, MII_BMCR, MII_READ) & ~BMCR_PDOWN);
+
/* erase previous misconfiguration */
if (np->driver_data & DEV_HAS_POWER_CNTRL)
nv_mac_reset(dev);
@@ -4872,6 +4877,10 @@ static int nv_close(struct net_device *d
if (np->wolenabled) {
writel(NVREG_PFF_ALWAYS|NVREG_PFF_MYADDR, base + NvRegPacketFilterFlags);
nv_start_rx(dev);
+ } else {
+ /* power down phy */
+ mii_rw(dev, np->phyaddr, MII_BMCR,
+ mii_rw(dev, np->phyaddr, MII_BMCR, MII_READ) | BMCR_PDOWN);
}
/* FIXME: power down nic */
^ permalink raw reply
* Re: e1000 driver and samba
From: Bruce Cole @ 2007-09-21 18:21 UTC (permalink / raw)
To: L F; +Cc: netdev, bacole
In-Reply-To: <780b6f780709210713s62f6d51s90eb0a54cda2a3fb@mail.gmail.com>
L F wrote:
> Aha. This doesn't seem to be in mr. Romieu's patch above: should it go
> in on top of that?
>
His newer
0002-r8169-workaround-against-ignored-TxPoll-writes-8168.patch
does the same thing as the older quoted version, and is also
included in the roll-up patch he pointed you to.
I agree re. performance, and don't want to clutter the thread
realtek issues. I just wanted to clarify this particular
realtek-samba issue in case it's relevant. For a long time folks
suspected similar culprits (bad cable, half duplex, etc.) when
it was the driver. Perhaps you should try doing a ping flood
between server&client during your test. That healed the
problem by keeping the queue busy in the realtek case.
^ permalink raw reply
* Re: [PATCH 1/2] bnx2: factor out gzip unpacker
From: Valdis.Kletnieks @ 2007-09-21 18:36 UTC (permalink / raw)
To: Denys Vlasenko; +Cc: David Miller, jeff, mchan, linux-kernel, netdev
In-Reply-To: <200709211905.23946.vda.linux@googlemail.com>
[-- Attachment #1: Type: text/plain, Size: 448 bytes --]
On Fri, 21 Sep 2007 19:05:23 BST, Denys Vlasenko said:
> I plan to use gzip compression on following drivers' firmware,
> if patches will be accepted:
>
> text data bss dec hex filename
> 17653 109968 240 127861 1f375 drivers/net/acenic.o
> 6628 120448 4 127080 1f068 drivers/net/dgrs.o
> ^^^^^^
Should this be redone to use the existing firmware loading framework to
load the firmware instead?
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply
* Re: [PATCH] PHYLIB: IRQ event workqueue handling fixes
From: Andrew Morton @ 2007-09-21 18:42 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: Andy Fleming, Jeff Garzik, netdev, linux-kernel
In-Reply-To: <Pine.LNX.4.64N.0709211334420.2724@blysk.ds.pg.gda.pl>
On Fri, 21 Sep 2007 13:51:12 +0100 (BST)
"Maciej W. Rozycki" <macro@linux-mips.org> wrote:
> On Thu, 20 Sep 2007, Andrew Morton wrote:
>
> > You always put boring, crappy, insufficient text in the for-the-changelog
> > section and interesting, useful, sufficient text in the not-for-the-changelog
> > section.
>
> I'll swap the sections in the future then. ;-) Frankly I was not sure
> whether the changelog was happy about being fed with lengthy explanations
> and it has not spoken out.
I think it's worth putting plenty of details in the changelog: it's compressed
on-disk and on-the-wire and is overall pretty cheap. If people don't
actually seek the information out, it has close to zero impact on them.
But on those occasions when people _do_ seek the information out (and it
can be years later) then they want every drop of information they can get.
Numerous times I've gone back to the 2.5.x mm/ changelogs to work out
what on earth we were thinking when we did something, and it has proved
quite useful in explaining the existing code, or in suggesting possible
problems which we had forgotten about by 2007.
otoh, you can get a lot of handy info by googling for strategic parts of
the kernel code, or by googling snippets of the existing-but-short
changelog. For example, this patch: google for "Keep track of
disable_irq_nosync() invocations" and voila. Perhaps we don't need
changelogs at all ;)
^ permalink raw reply
* Re: [PATCH 1/2] bnx2: factor out gzip unpacker
From: Denys Vlasenko @ 2007-09-21 19:18 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: David Miller, jeff, mchan, linux-kernel, netdev
In-Reply-To: <15775.1190399812@turing-police.cc.vt.edu>
On Friday 21 September 2007 19:36, Valdis.Kletnieks@vt.edu wrote:
> On Fri, 21 Sep 2007 19:05:23 BST, Denys Vlasenko said:
>
> > I plan to use gzip compression on following drivers' firmware,
> > if patches will be accepted:
> >
> > text data bss dec hex filename
> > 17653 109968 240 127861 1f375 drivers/net/acenic.o
> > 6628 120448 4 127080 1f068 drivers/net/dgrs.o
> > ^^^^^^
>
> Should this be redone to use the existing firmware loading framework to
> load the firmware instead?
Not in every case.
For example, bnx2 maintainer says that driver and
firmware are closely tied for his driver. IOW: you upgrade kernel
and your NIC is not working anymore.
Another argument is to make kernel be able to bring up NICs
without needing firmware images in initramfs/initrd/hard drive.
--
vda
^ permalink raw reply
* Re: [PATCH 1/2] bnx2: factor out gzip unpacker
From: Valdis.Kletnieks @ 2007-09-21 19:32 UTC (permalink / raw)
To: Denys Vlasenko; +Cc: David Miller, jeff, mchan, linux-kernel, netdev
In-Reply-To: <200709212018.06553.vda.linux@googlemail.com>
[-- Attachment #1: Type: text/plain, Size: 605 bytes --]
On Fri, 21 Sep 2007 20:18:06 BST, Denys Vlasenko said:
> On Friday 21 September 2007 19:36, Valdis.Kletnieks@vt.edu wrote:
> > Should this be redone to use the existing firmware loading framework to
> > load the firmware instead?
>
> Not in every case.
>
> For example, bnx2 maintainer says that driver and
> firmware are closely tied for his driver. IOW: you upgrade kernel
> and your NIC is not working anymore.
>
> Another argument is to make kernel be able to bring up NICs
> without needing firmware images in initramfs/initrd/hard drive.
OK, I can live with "considered and decided against". :)
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox