On 8/23/05, Leonid Grossman <[EMAIL PROTECTED]> wrote:
>
>
> > -Original Message-
> > From: Arnaldo Carvalho de Melo [mailto:[EMAIL PROTECTED]
> > Leonid,
> >
> > If not for performance the idea of having LRO, LSO, TSO, etc
> > implemented in software can possibly simplify the stack as it
> -Original Message-
> From: Arnaldo Carvalho de Melo [mailto:[EMAIL PROTECTED]
> Leonid,
>
> If not for performance the idea of having LRO, LSO, TSO, etc
> implemented in software can possibly simplify the stack as it
> would assume that all drivers implement those features, if
> n
On 8/23/05, Leonid Grossman <[EMAIL PROTECTED]> wrote:
>
> > > From: Andi Kleen <[EMAIL PROTECTED]>
> > > Date: Tue, 23 Aug 2005 01:44:34 +0200
> > >
> > > > To be fair the situation as seen from the Linux kernel software
> > > > perspective is very similar for TOE and for LSO - both
> > are paten
> > From: Andi Kleen <[EMAIL PROTECTED]>
> > Date: Tue, 23 Aug 2005 01:44:34 +0200
> >
> > > To be fair the situation as seen from the Linux kernel software
> > > perspective is very similar for TOE and for LSO - both
> are patented
> > > by someone and it might be better to not touch any of
Hi,
I'm pleased to show some promising preliminary, limited results
with the Linux kernel DCCP + CCID3 implementation available at:
http://www.kernel.org/git/?p=linux/kernel/git/acme/net-2.6.14.git
Server is an AMD Athlon 2000+ machine with a VIA Rhine II
ethernet card and the cl
applied
make sure to CC netdev@vger.kernel.org in the future.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Dale Farnsworth wrote:
[This patch was submitted on 22Mar2005 and jgarzik said,
"applied, thanks", but it may have been lost in the git transition.
I've updated it to current offsets.]
Signed-off-by: Dale Farnsworth <[EMAIL PROTECTED]>
1) Make sure to CC netdev@vger.kernel.org, not [EMAIL PROT
Just making sure netdev folks saw this.
I'll probably push this into 2.6.13 some time tomorrow.
--- Begin Message ---
The patch titled
negative timer loop with lots of IPv4 peers
has been added to the -mm tree. Its filename is
negative-timer-loop-with-lots-of-ipv4-peers.patch
Patc
From: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
Date: Mon, 22 Aug 2005 23:57:48 -0300
> i.e. to have a TSO software implementation used only when the card
> didn't supported TSO, same stuff, like you mentioned above, for LRO
> and LSO, probably/possibly simplifying the stack by making it assume
On 8/22/05, David S. Miller <[EMAIL PROTECTED]> wrote:
> From: Andi Kleen <[EMAIL PROTECTED]>
> Date: Tue, 23 Aug 2005 04:31:02 +0200
>
> > BTW a software only LRO would be quite imaginable too.
>
> Absolutely, and it would be excellent for prototyping.
>
> Most receive offload technologies can
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Tue, 23 Aug 2005 12:50:01 +1000
> Sorry, I didn't mean to say that pkt_len is an incorrect cut-off point,
> but that it's not a valid value for the MSS. So I'd like to see
>
> if (tcp_fragment(sk, skb, pkt_len, TCP_SKB_CB(skb)->tso_size))
>
On Mon, Aug 22, 2005 at 07:44:59PM -0700, David S. Miller wrote:
>
> It makes perfect sense. In your example, we want a 2*MSS TSO
> frame for the "not-SACKed" area, and the tail 1*MSS frame for
> the SACKed area. This provides exactly the necessary granularity
> in order to record the received SA
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Mon, 22 Aug 2005 22:54:50 +1000
> > + if (pcount > 1 &&
> > + (after(start_seq, TCP_SKB_CB(skb)->seq) ||
> > +before(end_seq, TCP_SKB_CB(skb)->end_seq))) {
> > + uns
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Tue, 23 Aug 2005 04:31:02 +0200
> BTW a software only LRO would be quite imaginable too.
Absolutely, and it would be excellent for prototyping.
Most receive offload technologies can be experimented with using a
software simulator that sits watching neti
On Mon, 22 Aug 2005 19:19:06 -0700 (PDT)
"David S. Miller" <[EMAIL PROTECTED]> wrote:
> From: Andi Kleen <[EMAIL PROTECTED]>
> Date: Tue, 23 Aug 2005 01:44:34 +0200
>
> > To be fair the situation as seen from the Linux kernel software perspective
> > is very similar for TOE and for LSO - both are
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Tue, 23 Aug 2005 01:44:34 +0200
> To be fair the situation as seen from the Linux kernel software perspective
> is very similar for TOE and for LSO - both are patented by someone
> and it might be better to not touch any of them because of that.
LRO requ
On Mon, 22 Aug 2005 08:57:45 -0700 (PDT)
"David S. Miller" <[EMAIL PROTECTED]> wrote:
> From: "Leonid Grossman" <[EMAIL PROTECTED]>
> Date: Mon, 22 Aug 2005 11:50:54 -0400
>
> > Christoph - sorry, but I don't see a reason to continue this debate.
> > Good luck fighting TOE patents - you are going
Gopalakrishnan Raman wrote:
Hi
I'm using 2.6.11.7 and debugging why my ESP tunnel mode does
not work between two 2.6 machines one of which is behind a NAT.
I'm using tcpdump to capture NAT-T packets on one of the hosts
and using espdecrypt (http://www.cs.rpi.edu/~flemej/freebsd/espdecrypt/)
to se
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Mon, 22 Aug 2005 13:04:31 +1000
> You need to update various counters likes packets_out since you're
> changing the skb_pcount of a packet that's on the retransmit queue.
Good point.
We would now have two spots which need to do the packets_out
updates,
David S. Miller <[EMAIL PROTECTED]> wrote:
> + if (pcount > 1 &&
> + (after(start_seq, TCP_SKB_CB(skb)->seq) ||
> +before(end_seq, TCP_SKB_CB(skb)->end_seq))) {
> + unsigned int pkt_len;
> +
>
On Sun, Aug 21, 2005 at 08:57:15PM -0700, David S. Miller wrote:
>
> Thinking about this some more... why would I need to use
> anyting other than "SKB"? SKB is where the front part of
> the split data is placed, and skb->next contains the
> subsequent data.
>
> So just using "skb" should be fine
>
> > It does not exist today AFAIK. The hope of such a solution will prevent
> > the inclusion of TOE technology that exists today?
>
>
> TOE has a solid track record of being a point-in-time solution with
> decreased features and increased maintenance headaches.
>
> That's what prevents its i
Thomas Graf wrote:
* Patrick McHardy <[EMAIL PROTECTED]> 2005-08-22 23:38
@@ -1364,7 +1365,7 @@ fn_trie_lookup(struct fib_table *tb, con
}
if (IS_LEAF(n)) {
-if (check_leaf(t, (struct leaf *)n, key, &plen, flp,
res, &ret))
+if ((ret == check_leaf(t, (s
> -Original Message-
> From: Christoph Lameter [mailto:[EMAIL PROTECTED]
Hi Christoph,
You got your subject backwards, but this is OK...
> How much will the permission cost for a hardware vendor to be
> allowed to implement LRO?
The question did not even occur to me until you asked
On Sun, 21 Aug 2005 16:19:26 -0700 (PDT)
"David S. Miller" <[EMAIL PROTECTED]> wrote:
> From: Andi Kleen <[EMAIL PROTECTED]>
> Date: Mon, 22 Aug 2005 01:13:21 +0200
>
> > > Basically, you'll have skb->free_callback(skb, ARG), and
> > > skb->free_callback_ARG. And when the SKB and it's memory
> >
> Another approach would be:
>
> 1) Determine that we don't care about the callback (ie. it gets
>reset to NULL) when the skb->dev changes, as would occur for
>forwarding, and certain kinds of firewalling and classification
>actions.
>
> 2) As a result of #1 we can put the callback i
John W. Linville wrote:
So, when a perfectly good incoming frame is dropped by the NIC
(generally due to lack of hardware resources), how should it be
counted? There appears to be some confusion or disagreement...
The e100 driver counts such a frame under the rx_dropped field of
its net_device_
On Sun, 21 Aug 2005, Leonid Grossman wrote:
> Ahh, I was curious to see if someone will bring this argument up - in
> fact, LRO legal issues do not exist, while TOE legal issues are quite
> big at the moment. I guess this is one of the reasons why OpenRDMA and
> other mainstream industry efforts d
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Mon, 22 Aug 2005 14:21:40 +1000
> > A further simplification seems possible, in that all of the
> > tp->*_out modifications can be keyed upon the "skb_ever_sent"
> > arg to tcp_fragment().
>
> Yes this is a good idea.
>
> > + if (skb_ever_sent) {
>
Thomas Graf wrote:
* Patrick McHardy <[EMAIL PROTECTED]> 2005-08-22 23:38
@@ -1364,7 +1365,7 @@ fn_trie_lookup(struct fib_table *tb, con
}
if (IS_LEAF(n)) {
- if (check_leaf(t, (struct leaf *)n, key, &plen, flp, res,
&ret))
+
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Mon, 22 Aug 2005 13:04:31 +1000
> > +
> > + fack_count += pcount;
> >
> >in_sack = !after(start_seq, TCP_SKB_CB(skb)->seq) &&
> >!before(end_seq, TCP_SKB_CB(skb)->end_seq);
>
* Patrick McHardy <[EMAIL PROTECTED]> 2005-08-22 23:38
> @@ -1364,7 +1365,7 @@ fn_trie_lookup(struct fib_table *tb, con
> }
>
> if (IS_LEAF(n)) {
> - if (check_leaf(t, (struct leaf *)n, key, &plen, flp,
> res, &ret))
> + if ((re
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Mon, 22 Aug 2005 05:00:17 +0200
> > Another approach would be:
> >
> > 1) Determine that we don't care about the callback (ie. it gets
> >reset to NULL) when the skb->dev changes, as would occur for
> >forwarding, and certain kinds of firewalling
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Mon, 22 Aug 2005 03:34:16 +0200
> In theory the NIC could store it in a separate data structure, but
> that would be wasteful IMHO because it would duplicate what a socket
> does. So it's best to add a last_rcv_cpu field to the struct sock
> and make sur
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.14/net/ipv6/ip6_fib.c
===
--- net-2.6.14.orig/net/ipv6/ip6_fib.c
+++ net-2.6.14/net/ipv6/ip6_fib.c
@@ -588,33 +588,35 @@ struct lookup_args {
struct in6_addr *addr;
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.14/net/ipv6/ip6_fib.c
===
--- net-2.6.14.orig/net/ipv6/ip6_fib.c
+++ net-2.6.14/net/ipv6/ip6_fib.c
@@ -617,11 +617,10 @@ static inline struct fib6_node *fib6_des
static st
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.14/net/ipv6/ip6_fib.c
===
--- net-2.6.14.orig/net/ipv6/ip6_fib.c
+++ net-2.6.14/net/ipv6/ip6_fib.c
@@ -198,6 +198,10 @@ static __inline__ void rt6_release(struc
Gidday,
Thanks for this patch. I have a few questions:
> Andi Kleen wrote:
> > The man page was supposed to document the kernel, so it's probably
> > a bug in the manpage. You should send a patch to the manpages
> > maintainers, with a warning in NOTES that the Linux behaviour
> > differs from
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.14/net/ipv6/ip6_fib.c
===
--- net-2.6.14.orig/net/ipv6/ip6_fib.c
+++ net-2.6.14/net/ipv6/ip6_fib.c
@@ -623,18 +623,12 @@ static struct fib6_node * fib6_lookup_1(
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.14/include/net/ip6_fib.h
===
--- net-2.6.14.orig/include/net/ip6_fib.h
+++ net-2.6.14/include/net/ip6_fib.h
@@ -124,6 +124,11 @@ struct rt6_statistics {
#define RTN_ROOT
Michael Kerrisk wrote:
> > -.I IP_RECVTTL
> > +.I IP_TTL
>
> So is it the case that this option was just wrongly named in the
> original page, or is the change here reflective of something that
> has changed in the kernel? (It doesn't look like the latter is
> true, but I thought it better to
> As far as i know, the code that implements PMTU discovery is located
> in net/ipv4/ip_output.c.
> It is independent of ipsec, it is valuable for all ipv4.
But when v r using IPsec the size of payload increases n hence when the
packet is send outward it can b dropped due to its size..So v have ag
Collection of cleanups for fib6_lookup() that used to live in my tree
for a while now.
Yoshfuji-san, what's the plan for CONFIG_IPV6_SUBTREES? Is MIPL
going to use it or can we remove it? For now I manually compiled
with CONFIG_IPV6_SUBTREES=1 but I have no idea how to actually
test it.
-
To unsu
> > > control message with the time to live
> > > field of the received packet as a byte. Not supported for
> > > .B SOCK_STREAM
> > > @@ -789,6 +789,20 @@ received datagrams. Linux has the more g
> > > .I IP_PKTINFO
> > > for the same task.
> > > .PP
> > > +Some BSD sockets implementations a
Patrick McHardy wrote:
Vladimir B. Savkin wrote:
The same with "blackhole" routes, looks like they are ignored.
This patch should fix it. Please try it and report if it helps.
Please wait with testing, I must have done something stupid, booting
with this patch results in multiple oopses :)
In article <[EMAIL PROTECTED]> (at Mon, 22 Aug 2005 13:08:28 +0200), Thomas
Graf <[EMAIL PROTECTED]> says:
> Collection of cleanups for fib6_lookup() that used to live in my tree
> for a while now.
>
> Yoshfuji-san, what's the plan for CONFIG_IPV6_SUBTREES? Is MIPL
> going to use it or can we re
On Sun, Aug 21, 2005 at 11:29:11PM -0700, David S. Miller wrote:
>
> Ok, this is a full redo of the "do not disable TSO on loss" patch
> including all of the refinements and fixes we've discussed so
> far.
Thanks Dave.
> +extern int tcp_fragment(struct sock *, struct sk_buff *, u32, unsigned int
Vladimir B. Savkin wrote:
А simple test case (2.6.13-rc6, fib_trie enabled):
# ip ro
172.16.16.0/22 dev vlan0173 proto kernel scope link src 172.16.18.1
172.16.0.0/16 via 172.16.16.1 dev vlan0173
10.0.0.0/8 via 172.16.16.1 dev vlan0173
# ip ro add unreachable 10.10.10.10
# ip ro flush cac
qdisc_create_dflt() is missing to destroy the newly allocated
default qdisc if the initialization fails resulting in leaks
of all kinds. The only caller in mainline which may trigger
this bug is sch_tbf.c in tbf_create_dflt_qdisc().
Note: qdisc_create_dflt() doesn't fulfill the official locking
On Mon, 22 Aug 2005, Leonid Grossman wrote:
> With several tens of already granted and very broad TOE-related patents,
> this statement sounds rather naïve, and I just wish anyone good luck
> defending it in the future...
Ummm. TOE has been around for 20 years now and there is lots of prior art.
From: Christoph Lameter <[EMAIL PROTECTED]>
Date: Mon, 22 Aug 2005 08:21:34 -0700 (PDT)
> We would not have to put the patented
> LRO algorithm into the TCP layer
There is no "algorithm" to put into the Linux kernel in order to
support LRO.
The kernel just passively receives larger than MSS siz
* David S. Miller <[EMAIL PROTECTED]> 2005-08-22 10:07
> I don't want to create too much conflicts with your MIPV6
> work. Would you prefer to integrate Thomas's cleanups into
> your tree? Please let me know.
We can also wait and I'll merge those patches once you're
both in sync again, no proble
> -Original Message-
> From: Christoph Lameter [mailto:[EMAIL PROTECTED]
> Sent: Monday, August 22, 2005 8:22 AM
> To: Leonid Grossman
> Cc: David S. Miller; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED];
> netdev@vger.kernel.org; [EMAIL PROTECTED]
> Subject: RE: LRO Paten
From: "Leonid Grossman" <[EMAIL PROTECTED]>
Date: Mon, 22 Aug 2005 11:50:54 -0400
> Christoph - sorry, but I don't see a reason to continue this debate.
> Good luck fighting TOE patents - you are going to need it.
I would like to thank Lenoid for making me aware of the
legal concerns TOE brings a
On Thu, Aug 18, 2005 at 03:01:39PM -0700, David S. Miller wrote:
> Yes, it all boils down to what we intend rx_errors to mean.
> Purely hardware errors? Or also include errors due to running
> out of resources necessary for the card to continue operating
> correctly (ie. packet buffer memory exha
Add SNMP_MIB_SENTINEL to the definition of the sctp_snmp_list so that
the output routine in proc correctly terminates. This was causing some
problems running on ia64 systems.
Signed-of-by: Vlad Yasevich <[EMAIL PROTECTED]>
diff --git a/net/sctp/proc.c b/net/sctp/proc.c
--- a/net/sctp/proc.c
+++
56 matches
Mail list logo
