I do have a pretty nice cluster of linux boxes if you need lmbench results
or something like that. Linux and the rest of the unix stuff for whatever
that is worth...
work ~/LMbench2/bin ls -1
alpha-glibc22-linux # need to upgrade to debian 4
hppa-glibc23-linux
hppa-hpux11
ia64-glibc23
On Mon, 01 Oct 2007, jamal wrote:
> On Mon, 2007-01-10 at 00:11 -0400, Bill Fink wrote:
>
> > Have you done performance comparisons for the case of using 9000-byte
> > jumbo frames?
>
> I havent, but will try if any of the gige cards i have support it.
>
> As a side note: I have not seen any us
On Mon, Oct 01, 2007 at 08:50:50PM -0700, David Miller wrote:
> From: [EMAIL PROTECTED] (Larry McVoy)
> Date: Mon, 1 Oct 2007 19:20:59 -0700
>
> > A short summary is "can someone please post a test program that sources
> > and sinks data at the wire speed?" because apparently I'm too old and
> >
From: [EMAIL PROTECTED] (Larry McVoy)
Date: Mon, 1 Oct 2007 19:20:59 -0700
> A short summary is "can someone please post a test program that sources
> and sinks data at the wire speed?" because apparently I'm too old and
> clueless to write such a thing.
You're not showing us your test program s
From: Ben Greear <[EMAIL PROTECTED]>
Date: Mon, 01 Oct 2007 17:24:26 -0700
> David Miller wrote:
> > From: Ben Greear <[EMAIL PROTECTED]>
> > Date: Mon, 01 Oct 2007 16:49:06 -0700
> >
> >> For 'real' hardware, it seems that the netif_stop_queue and
> >> netif_wake_queue methods handle stopping an
Hi,
I just find out this IFA_F_NODAD was not in the kernel used in my test
bed which is 2.6.17. So I tried to modify the code in ipv6/addrconf.c by
myself to remove the DAD:
if (!max_addresses ||
ipv6_count_addresses(in6_dev) < max_addresses)
Corey Hickey wrote:
> Patrick McHardy wrote:
>
>>> +nest = RTA_NEST_COMPAT(skb, TCA_OPTIONS, sizeof(opt), &opt);
>>> +
>>> +RTA_PUT_U32(skb, TCA_SFQ_QUANTUM, q->quantum);
>>> +RTA_PUT_U32(skb, TCA_SFQ_PERTURB, q->perturb_period);
>>> +RTA_PUT_U32(skb, TCA_SFQ_LIMIT, q->limit);
>>
Corey Hickey wrote:
> Patrick McHardy wrote:
>
>>> +static void sfq_destroy(struct Qdisc *sch)
>>> +{
>>> +struct sfq_sched_data *q = qdisc_priv(sch);
>>> +sfq_q_destroy(q);
>>> +}
>>
>>
>> It does look pointless, after applying all patches sfq_destroy still
>> remains a simply wrapper aro
Corey Hickey wrote:
> Patrick McHardy wrote:
>
>>> -sch->qstats.drops++;
>>
>> A line in the changelog explaining that this was increased twice
>> would have been nice.
>
>
> Certainly; I think I didn't realize, when you originally pointed out the
> duplicate incrementing, that it was a bug
On Mon, Oct 01, 2007 at 07:14:37PM -0700, Linus Torvalds wrote:
>
>
> On Mon, 1 Oct 2007, Larry McVoy wrote:
> >
> > but the client looks like
> >
> > connect(3, {sa_family=AF_INET, sin_port=htons(31235),
> > sin_addr=inet_addr("10.3.9.1")}, 16) = 0
> > read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
On Mon, 1 Oct 2007, Larry McVoy wrote:
>
> but the client looks like
>
> connect(3, {sa_family=AF_INET, sin_port=htons(31235),
> sin_addr=inet_addr("10.3.9.1")}, 16) = 0
> read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576)
> = 2896
> read(3, "\0\0\0\0\0\0\0\0\0\0\0\
On Sat, Sep 29, 2007 at 11:02:32AM -0700, Linus Torvalds wrote:
> On Sat, 29 Sep 2007, Larry McVoy wrote:
> > I haven't kept up on switch technology but in the past they were much
> > better than you are thinking. The Kalpana switch that I had modified
> > to support vlans (invented by yours truly
David Miller wrote:
From: Ben Greear <[EMAIL PROTECTED]>
Date: Mon, 01 Oct 2007 16:49:06 -0700
For 'real' hardware, it seems that the netif_stop_queue and
netif_wake_queue methods handle stopping and waking the
higher level senders, but for virtual devices with no
queues, how does this work?
From: Ben Greear <[EMAIL PROTECTED]>
Date: Mon, 01 Oct 2007 16:49:06 -0700
> For 'real' hardware, it seems that the netif_stop_queue and
> netif_wake_queue methods handle stopping and waking the
> higher level senders, but for virtual devices with no
> queues, how does this work?
They don't queue
Hello!
I am having some trouble figuring out how virtual interfaces
(such as mac-vlans) can wake up writers (such as udp sockets).
For 'real' hardware, it seems that the netif_stop_queue and
netif_wake_queue methods handle stopping and waking the
higher level senders, but for virtual devices wit
On Sun, 2007-09-30 at 14:11 -0400, jamal wrote:
> Here are some non-batching related changes that i have in my batching
> tree. Like the e1000e, they make the xmit code more readable.
> I wouldnt mind if you take them over.
>
Jamal, in tg3_enqueue_buggy(), we may have to call tg3_tso_bug() which
From: Dale Farnsworth <[EMAIL PROTECTED]>
This driver erroneously zeros dev->tx_queue_len, since
mp->tx_ring_size has not yet been initialized. Actually,
the driver shouldn't modify tx_queue_len at all and should
leave the value set by alloc_etherdev(), currently 1000.
Signed-off-by: Dale Farnsw
From: "Ilpo_Järvinen" <[EMAIL PROTECTED]>
Date: Mon, 1 Oct 2007 15:29:40 +0300
> This fixes the newreno fackets_out case, which turned out to be
> not related to the Cedric's case being under investigation. Two
> trivial comment patches, and frto with high-speed seqno
> wrap-around protection. Co
On Mon, 01 Oct 2007 15:15:59 -0600
"Chris Friesen" <[EMAIL PROTECTED]> wrote:
> Stephen Hemminger wrote:
>
> > Adding fragmentation support to skge driver is on my list of
> > possible extensions. sky2 driver already supports it (yet one
> > more feature that the vendor sk98lin driver doesn't do)
Jeff Garzik wrote:
The sk98lin driver is going away, please don't use it.
It's unmaintained and full of known bugs.
Okay...so it looks like the proper driver for the Marvell Yukon 88E8062
is the sky2 driver, and this one does avoid order>0 allocations. Am I
on track?
Chris
-
To unsubscri
Stephen Hemminger wrote:
Adding fragmentation support to skge driver is on my list of
possible extensions. sky2 driver already supports it (yet one
more feature that the vendor sk98lin driver doesn't do).
Thanks for speaking up. As I mentioned in my email to Jeff it looks
like the sky2 drive
On Mon, 01 Oct 2007 14:35:48 -0600
"Chris Friesen" <[EMAIL PROTECTED]> wrote:
>
> Hi all,
>
> We're considering some hardware that uses the sk98lin network hardware,
> and we'll be using jumbo frames. Looking at the driver, when using a
> 9KB MTU it seems like it would end up trying to atomic
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Mon, 01 Oct 2007 22:10:03 +0200
> So maybe the following patch is necessary...
>
> I believe IPV6 & DCCP are immune to this problem.
>
> Thanks again Denys for spotting this.
>
> Eric
>
> [PATCH] TCP : secure_tcp_sequence_number() should not use a t
Chris Friesen wrote:
We're considering some hardware that uses the sk98lin network hardware,
and we'll be using jumbo frames. Looking at the driver, when using a
9KB MTU it seems like it would end up trying to atomically allocate a
16KB buffer.
The sk98lin driver is going away, please don't
Patrick McHardy wrote:
Corey Hickey wrote:
Re-implement sfq_change() and enable Qdisc_opts.change so "tc qdisc
change" will work.
+static int sfq_change(struct Qdisc *sch, struct rtattr *opt)
+{
+ ...
+
+ /* finish up */
+ if (q->perturb_period) {
+ q->perturb
Patrick McHardy wrote:
Corey Hickey wrote:
perturb_period is currently a signed integer, but I can't see any good
reason why this is so--a negative perturbation period will add a timer
that expires in the past, causing constant perturbation, which makes
hashing useless.
if (q->perturb_p
Patrick McHardy wrote:
Corey Hickey wrote:
+
+#define GET_PARAM(dst, nest, compat) do { \
+ struct rtattr *rta = tb[(nest) - 1]; \
+ if (rta) \
+ (dst) = RTA_GET_U32(rta); \
+ else if ((compat)) \
+ (dst) = (compat); \
+} while (0)
An inline funct
Patrick McHardy wrote:
Corey Hickey wrote:
Move sfq_q_destroy() to above sfq_q_init() so that it can be used
by an error case in a later patch.
Move sfq_destroy() as well, for clarity.
This patch looks pointless, just put them where you need them
in the patch introducing them.
As you wish.
Patrick McHardy wrote:
Corey Hickey wrote:
Make hash divisor user-configurable.
@@ -120,7 +121,7 @@ static __inline__ unsigned sfq_fold_hash(struct
sfq_sched_data *q, u32 h, u32 h1
/* Have we any rotation primitives? If not, WHY? */
h ^= (h1<>(0x1F - pert));
h ^= h>>
Patrick McHardy wrote:
Corey Hickey wrote:
Make a new function sfq_q_enqueue() that operates directly on the
queue data. This will be useful for implementing sfq_change() in
a later patch. A pleasant side-effect is reducing most of the
duplicate code in sfq_enqueue() and sfq_requeue().
Similarl
Patrick McHardy wrote:
Corey Hickey wrote:
The sfq_destroy() --> sfq_q_destroy() change looks pointless here,
but it's cleaner to split now and add code to sfq_q_destroy() in a
later patch.
+static void sfq_destroy(struct Qdisc *sch)
+{
+ struct sfq_sched_data *q = qdisc_priv(sch);
+
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Mon, 1 Oct 2007 11:24:17 -0700
> Recent change in hard header broke build of these old drivers.
>
> Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
Applied, thanks Stephen.
-
To unsubscribe from this list: send the line "unsubscribe netdev"
Yes it has this problem. I've observed it in practice on a busy firewall.
-John
Chris Friesen wrote:
Hi all,
We're considering some hardware that uses the sk98lin network hardware,
and we'll be using jumbo frames. Looking at the driver, when using a
9KB MTU it seems like it would end u
Hi all,
We're considering some hardware that uses the sk98lin network hardware,
and we'll be using jumbo frames. Looking at the driver, when using a
9KB MTU it seems like it would end up trying to atomically allocate a
16KB buffer.
Has anyone heard of this been a problem? It would seem li
So maybe the following patch is necessary...
I believe IPV6 & DCCP are immune to this problem.
Thanks again Denys for spotting this.
Eric
[PATCH] TCP : secure_tcp_sequence_number() should not use a too fast clock
TCP V4 sequence numbers are 32bits, and RFC 793 assumed a 250 KHz clock.
In orde
Previously, bitbanged MDIO was only supported in individual
hardware-specific drivers. This code factors out the higher level
protocol implementation, reducing the hardware-specific portion to
functions setting direction, data, and clock.
Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
---
drivers
Commit 4fa57c9ea9f36f9ca852f3a88ca5d2f1aebbc960
("Make NAPI polling independent of struct net_device objects.")
introduced some build breakage in the napi rx function.
Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
---
drivers/net/fs_enet/fs_enet-main.c |4 ++--
1 files changed, 2 insertions(+
Mostly a bunch of __iomem annotations.
Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
---
drivers/net/fs_enet/fs_enet-main.c | 18 +-
drivers/net/fs_enet/fs_enet.h | 30
drivers/net/fs_enet/mac-fcc.c | 71
drivers/net/fs
The existing OF glue code was crufty and broken. Rather than fix it, it
will be removed, and the ethernet driver now talks to the device tree
directly.
The old, non-CONFIG_PPC_CPM_NEW_BINDING code can go away once CPM
platforms are dropped from arch/ppc (which will hopefully be soon), and
existin
Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
---
drivers/net/fs_enet/mii-bitbang.c | 270 -
1 files changed, 54 insertions(+), 216 deletions(-)
diff --git a/drivers/net/fs_enet/mii-bitbang.c
b/drivers/net/fs_enet/mii-bitbang.c
index 7cf132f..b8e4a73 100644
-
At least some hardware driven by this driver needs receive buffers
to be aligned on a 16-byte boundary. This usually happens by chance,
but it breaks if slab debugging is enabled.
Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
---
drivers/net/fs_enet/fs_enet-main.c | 21 +++--
d
These macros accomplish nothing other than defeating type checking.
This patch also fixes one instance of the wrong register size being
used that was revealed by enabling type checking.
Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
---
drivers/net/fs_enet/mac-fcc.c | 25 ---
It is needed for strstr().
Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
---
include/linux/fs_enet_pd.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/linux/fs_enet_pd.h b/include/linux/fs_enet_pd.h
index 543cd3c..815c6f9 100644
--- a/include/linux/fs_enet_pd.h
+
Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
---
This patch series applies to the net-2.6.24 branch.
drivers/net/fs_enet/fs_enet-main.c | 85 ---
drivers/net/fs_enet/fs_enet.h |4 +-
drivers/net/fs_enet/mac-fcc.c |1 -
drivers/net/fs_enet/mii-b
Signed-off-by: Ron Mercer <[EMAIL PROTECTED]>
---
drivers/net/qla3xxx.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/qla3xxx.c b/drivers/net/qla3xxx.c
index 69da95b..c3fe1c7 100755
--- a/drivers/net/qla3xxx.c
+++ b/drivers/net/qla3xxx.c
@@ -2248,6 +2248,7 @
Fix 4032 chip undocumented "feature" where bit-8 is set
if the inbound completion is for a VLAN.
Signed-off-by: Ron Mercer <[EMAIL PROTECTED]>
---
drivers/net/qla3xxx.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/net/qla3xxx.c b/drivers/net/qla3xxx.c
inde
Jeff,
This is the second submission... First was in August. Thanks, Ron
The following two patches fix:
An undocumented "feature" where the 4032 chip sets bit-7
of the opcode for an inbound completion if it's for a VLAN.
The access of stale data on a completion entry.
These patches were built an
Recent change in hard header broke build of these old drivers.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
drivers/net/hamradio/dmascc.c |2 +-
drivers/net/hamradio/scc.c|2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/hamradio/dmascc.c b/
Hi,
YOSHIFUJI Hideaki / 吉藤英明 wrote:
>>> I think it'd also be better if you add the check to be:
>>>
>>> if (ipv6_addr_type(target) &
>>> (IPV6_ADDR_LINKLOCAL|IPV6_ADDR_UNICAST))
>>>
>>> or something along those lines, rather than reproducing ipv6_addr_type()
>>> code
>>> separate
Arnaldo, Al Viro, and Yoshifuji -
sorry for having wasted your time with this one. You are right, that was
complete nonsense.
I don't know where my mind was - even my test program used to `prove' this was
screwed up.
So nothing wrong here and thank you very much for your clarifying comments.
Patrick McHardy <[EMAIL PROTECTED]> writes:
> Denis V. Lunev wrote:
>> By the way, Patrick, this looks like nlk->pid == 0 if and only if this
>> is a kernel socket. Right?
>>
>
> Thats correct.
>
>> I have told with Alexey Kuznetsov and we have discrovered a way to get
>> rid of
>> skb_que
Denys a écrit :
Well, i can play a bit more on "live" servers. I have now hot-swap server with
full gentoo, where i can rebuild any kernel you want, with any applied patch.
But it looks more like not overhead, load becoming high too "spiky", and it is
not just permantenly higher. Also it is not
Denis V. Lunev wrote:
By the way, Patrick, this looks like nlk->pid == 0 if and only if this
is a kernel socket. Right?
Thats correct.
I have told with Alexey Kuznetsov and we have discrovered a way to get
rid of
skb_queue_tail(&sk->sk_receive_queue, skb);
sk->sk_data_ready
Jan-Bernd Themann wrote:
Hi,
On Monday 01 October 2007 16:44, Jeff Garzik wrote:
Jan-Bernd Themann wrote:
Due to stability issues in high load situations the HW queue handling
has to be changed. The HW queues are now stopped and restarted again instead
of destroying and allocating new HW queue
Patrick McHardy wrote:
> Denis V. Lunev wrote:
>> netlink_kernel_create can be called with NULL as an input callback in several
>> places, f.e. in kobject_uevent_init. This means that if one sends packet from
>> user to kernel for such a socket, the packet will be leaked in the socket
>> queue fore
Hi,
On Monday 01 October 2007 16:44, Jeff Garzik wrote:
> Jan-Bernd Themann wrote:
> > Due to stability issues in high load situations the HW queue handling
> > has to be changed. The HW queues are now stopped and restarted again instead
> > of destroying and allocating new HW queues.
> >
> > Si
Jan-Bernd Themann wrote:
Due to stability issues in high load situations the HW queue handling
has to be changed. The HW queues are now stopped and restarted again instead
of destroying and allocating new HW queues.
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
May I presume this is f
Hi
On Sunday 30 September 2007 18:20, Anton Blanchard wrote:
>
> Hi,
>
> I booted 2.6.23-rc8 and noticed that ehea loves its workqueues:
> (notice also that the ehea_driver_wq/XXX exceeds TASK_COMM_LEN).
>
> Since they are both infrequent events and not performance critical
> (memory hotplug a
Denis V. Lunev wrote:
> netlink_kernel_create can be called with NULL as an input callback in several
> places, f.e. in kobject_uevent_init. This means that if one sends packet from
> user to kernel for such a socket, the packet will be leaked in the socket
> queue forever.
>
> This patch adds a s
Due to stability issues in high load situations the HW queue handling
has to be changed. The HW queues are now stopped and restarted again instead
of destroying and allocating new HW queues.
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
---
drivers/net/ehea/ehea.h |4 +-
drivers
Em Mon, Oct 01, 2007 at 02:39:28PM +0100, Gerrit Renker escreveu:
> Quoting YOSHIFUJI Hideaki:
> |
> | > [TCP]: break missing at end of switch statement
> | >
> | > Signed-off-by: Gerrit Renker <[EMAIL PROTECTED]>
> | > ---
> | > --- a/net/ipv4/tcp_input.c
> | > +++ b/net/ipv4/tcp_input.c
>
Denis V. Lunev wrote:
> The code in netfilter/nfnetlink.c and in ./net/netlink/genetlink.c looks
> like outdated copy/paste from rtnetlink.c. Push them into sync with the
> original.
>
> Changes from v1:
> - deleted comment in nfnetlink_rcv_msg by request of Patrick McHardy
Thanks.
>
> Signed-o
netlink_kernel_create can be called with NULL as an input callback in several
places, f.e. in kobject_uevent_init. This means that if one sends packet from
user to kernel for such a socket, the packet will be leaked in the socket
queue forever.
This patch adds a simple generic cleanup callback for
The code in netfilter/nfnetlink.c and in ./net/netlink/genetlink.c looks
like outdated copy/paste from rtnetlink.c. Push them into sync with the
original.
Changes from v1:
- deleted comment in nfnetlink_rcv_msg by request of Patrick McHardy
Signed-off-by: Denis V. Lunev <[EMAIL PROTECTED]>
--- .
> On Fri, Sep 28, 2007 at 09:47:37PM -0700, David Miller wrote:
>> There are two things we (might) need to guard against, one local and
>> one remote.
>
> Right I was focusing on the local threat.
>
>> If you do a per-user limit, apache would basically just stop at that
>> redzone point. In some s
Herbert Xu wrote:
> On Fri, Sep 28, 2007 at 09:51:59PM -0700, David Miller wrote:
>> There is a per-socket send buffer limit, and there is a per-user open
>> file descriptor limit. Multiply the two to determine how much system
>> memory the user can consume using sockets.
>
> We do have these limi
Corey Hickey wrote:
> This fixes the ambiguity between, for example:
> tc qdisc change ... perturb 0
> tc qdisc change ...
>
> Without this patch, there is no way for SFQ to differentiate between
> a parameter specified to be 0 and a parameter that was omitted.
>
> diff --git a/net/sched/sch_sfq
Evgeniy Polyakov wrote:
> On Fri, Sep 28, 2007 at 10:41:31PM +0900, Satoshi OSHIMA
([EMAIL PROTECTED]) wrote:
>> This patch introduces memory usage measurement for UDP.
>>
>> These 3 points were updated.
>>
>> - UDP specific codes in IP layer were removed.
>>
>> - atomic_sub() in a loop was removed
In article <[EMAIL PROTECTED]> (at Mon, 1 Oct 2007 13:32:43 +0100), Gerrit
Renker <[EMAIL PROTECTED]> says:
> [TCP]: break missing at end of switch statement
>
> Signed-off-by: Gerrit Renker <[EMAIL PROTECTED]>
> ---
> --- a/net/ipv4/tcp_input.c
> +++ b/net/ipv4/tcp_input.c
> @@ -3129,6 +3129,7
Corey Hickey wrote:
> perturb_period is currently a signed integer, but I can't see any good
> reason why this is so--a negative perturbation period will add a timer
> that expires in the past, causing constant perturbation, which makes
> hashing useless.
>
> if (q->perturb_period) {
>
Quoting YOSHIFUJI Hideaki:
|
| > [TCP]: break missing at end of switch statement
| >
| > Signed-off-by: Gerrit Renker <[EMAIL PROTECTED]>
| > ---
| > --- a/net/ipv4/tcp_input.c
| > +++ b/net/ipv4/tcp_input.c
| > @@ -3129,6 +3129,7 @@ static void tcp_reset(struct sock *sk)
| >
Corey Hickey wrote:
> Re-implement sfq_change() and enable Qdisc_opts.change so "tc qdisc
> change" will work.
>
> +static int sfq_change(struct Qdisc *sch, struct rtattr *opt)
> +{
> + ...
> +
> + /* finish up */
> + if (q->perturb_period) {
> + q->perturb_timer.expires =
Corey Hickey wrote:
> Make hash divisor user-configurable.
>
> @@ -120,7 +121,7 @@ static __inline__ unsigned sfq_fold_hash(struct
> sfq_sched_data *q, u32 h, u32 h1
> /* Have we any rotation primitives? If not, WHY? */
> h ^= (h1<>(0x1F - pert));
> h ^= h>>10;
> - return h
Corey Hickey wrote:
> The sfq_destroy() --> sfq_q_destroy() change looks pointless here,
> but it's cleaner to split now and add code to sfq_q_destroy() in a
> later patch.
>
> +static void sfq_destroy(struct Qdisc *sch)
> +{
> + struct sfq_sched_data *q = qdisc_priv(sch);
> + sfq_q_destro
Corey Hickey wrote:
> Move sfq_q_destroy() to above sfq_q_init() so that it can be used
> by an error case in a later patch.
>
> Move sfq_destroy() as well, for clarity.
This patch looks pointless, just put them where you need them
in the patch introducing them.
-
To unsubscribe from this list:
On Mon, 2007-01-10 at 00:11 -0400, Bill Fink wrote:
> Have you done performance comparisons for the case of using 9000-byte
> jumbo frames?
I havent, but will try if any of the gige cards i have support it.
As a side note: I have not seen any useful gains or losses as the packet
size approaches
Corey Hickey wrote:
> Make a new function sfq_q_enqueue() that operates directly on the
> queue data. This will be useful for implementing sfq_change() in
> a later patch. A pleasant side-effect is reducing most of the
> duplicate code in sfq_enqueue() and sfq_requeue().
>
> Similarly, make a new
Resend for maillists (was discareded cause of encoding issues as SPAM).
Everything looks fine, for sure. Confirmed on second server.
On Mon, 01 Oct 2007 10:20:07 +0200, Eric Dumazet wrote
> > Well, i can play a bit more on "live" servers. I have now hot-swap server
> > with
> > full gentoo, wh
On Mon, 2007-01-10 at 12:42 +0200, Patrick McHardy wrote:
> jamal wrote:
> > + while ((skb = __skb_dequeue(skbs)) != NULL)
> > + q->ops->requeue(skb, q);
>
>
> ->requeue queues at the head, so this looks like it would reverse
> the order of the skbs.
Excellent catch! thanks; i will
On Mon, Oct 01, 2007 at 02:02:10PM +0100, Gerrit Renker wrote:
> Quoting Al Viro:
> | On Mon, Oct 01, 2007 at 01:32:43PM +0100, Gerrit Renker wrote:
> | > [TCP]: break missing at end of switch statement
> | >
> | > Signed-off-by: Gerrit Renker <[EMAIL PROTECTED]>
> | > ---
> | > --- a/net/ip
Denis V. Lunev wrote:
> The code in netfilter/nfnetlink.c and in ./net/netlink/genetlink.c looks
> like outdated copy/paste from rtnetlink.c. Push them into sync with the
> original.
>
> int nfnetlink_subsys_register(const struct nfnetlink_subsystem *n)
> @@ -149,7 +137,7 @@ static int nfnetlink
Quoting Al Viro:
| On Mon, Oct 01, 2007 at 01:32:43PM +0100, Gerrit Renker wrote:
| > [TCP]: break missing at end of switch statement
| >
| > Signed-off-by: Gerrit Renker <[EMAIL PROTECTED]>
| > ---
| > --- a/net/ipv4/tcp_input.c
| > +++ b/net/ipv4/tcp_input.c
| > @@ -3129,6 +3129,7 @@ sta
The code in netfilter/nfnetlink.c and in ./net/netlink/genetlink.c looks
like outdated copy/paste from rtnetlink.c. Push them into sync with the
original.
Signed-off-by: Denis V. Lunev <[EMAIL PROTECTED]>
--- ./net/netfilter/nfnetlink.c.nlk32007-10-01 09:47:53.0 +0400
+++ ./net/netfil
On Mon, Oct 01, 2007 at 01:32:43PM +0100, Gerrit Renker wrote:
> [TCP]: break missing at end of switch statement
>
> Signed-off-by: Gerrit Renker <[EMAIL PROTECTED]>
> ---
> --- a/net/ipv4/tcp_input.c
> +++ b/net/ipv4/tcp_input.c
> @@ -3129,6 +3129,7 @@ static void tcp_reset(struct sock *sk)
>
Sean,
Not so simple.
How does client application knows where to connect?
Does this proposal forces applications to choose
the "right" network?
Currently, MPA or ULP and not applications handle it.
Why would we want to change that?
Sean,
I may be beating the dead horse,
but I recall that one of the
[TCP]: break missing at end of switch statement
Signed-off-by: Gerrit Renker <[EMAIL PROTECTED]>
---
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -3129,6 +3129,7 @@ static void tcp_reset(struct sock *sk)
return;
default:
s
In case somebody has a suggestion about a better place for this
check, which must guarantee execution "early enough" (i.e,
before the wrap can occur), I'm very open to them.
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
net/ipv4/tcp_input.c |3 +++
1 files changed, 3 insertions(+), 0 d
Hi Dave,
This fixes the newreno fackets_out case, which turned out to be
not related to the Cedric's case being under investigation. Two
trivial comment patches, and frto with high-speed seqno
wrap-around protection. Compile tested. Please apply to
net-2.6.24.
--
i.
-
To unsubscribe from this
This was found due to bug report from Cedric Le Goater though
it turned this turned out to be unrelated bug.
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
net/ipv4/tcp_output.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/t
Just came across what RFC2018 states about generation of valid
SACK blocks in case of reneging. Alter comment a bit to point
out clearly.
IMHO, there isn't any reason to change code because the
validation is there for a purpose (counters will inform user
about decision TCP made if this case ever s
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
net/ipv4/tcp_input.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 2286361..135f046 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -1467,8 +1467
David Miller <[EMAIL PROTECTED]> writes:
>
> Furthermore, prequeue puts the stack input processing work into user
> context, which means that the users will be charged more fairly for
> the work that is done for them.
For more details on this people might want to read the old Lazy Receiver
Proces
Not able to compile kernel with patch
drivers/built-in.o: In function `secure_tcp_sequence_number':
(.text+0x3ad02): undefined reference to `__divdi3'
make: *** [.tmp_vmlinux1] Error 1
On Mon, 01 Oct 2007 10:20:07 +0200, Eric Dumazet wrote
> Denys a :
> > Well, i can play a bit more on "live" ser
Hello.
In article <[EMAIL PROTECTED]> (at Sat, 29 Sep 2007 10:04:48 +0900 (JST)),
YOSHIFUJI Hideaki / 吉藤英明 <[EMAIL PROTECTED]> says:
> In article <[EMAIL PROTECTED]> (at Fri, 28 Sep 2007 17:50:38 -0700), David
> Stevens <[EMAIL PROTECTED]> says:
>
> > Brian,
> > A multicast address sho
In article <[EMAIL PROTECTED]> (at Mon, 01 Oct 2007 11:53:27 +0800), Xia Yang
<[EMAIL PROTECTED]> says:
> I would like to ask for help on how to remove or disable the DAD process
> properly, as long as the node can send, receive and forward packets
> immediately after a new IPv6 address is genera
Hi,
after reading about issues with the nics on kontron boards I did a
bios upgrade,
but this did not change anything.
However, yesterday the nic (onboard) I used died. No link at all,
after switching to
the next onboard nic I got a NETDEV transmit timeout with that one on
kernel 2.6.22-r2.
It se
Hello.
In article <[EMAIL PROTECTED]> (at Sat, 29 Sep 2007 19:47:20 +0200), Pierre
Ynard <[EMAIL PROTECTED]> says:
> As discussed before, this patch provides userland with a way to access
> relevant options in Router Advertisements, after they are processed and
> validated by the kernel. Extra o
Please apply to 2.6.23.
---
dm9601 didn't take the ethernet header into account when calculating
RX MTU, causing packets bigger than 1486 to fail.
Signed-off-by: Peter Korsgaard <[EMAIL PROTECTED]>
---
drivers/net/usb/dm9601.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux
jamal wrote:
> +static inline int
> +dev_requeue_skbs(struct sk_buff_head *skbs, struct net_device *dev,
> +struct Qdisc *q)
> +{
> +
> + struct sk_buff *skb;
> +
> + while ((skb = __skb_dequeue(skbs)) != NULL)
> + q->ops->requeue(skb, q);
->requeue queues at the h
There is no need to process outstanding netlink user->kernel packets
during rtnl_unlock now. There is no rtnl_trylock in the rtnetlink_rcv
anymore.
Normal code path is the following:
netlink_sendmsg
netlink_unicast
netlink_sendskb
skb_queue_tail
netlink_data_ready
1 - 100 of 106 matches
Mail list logo
