* Re: [RFC/PATCH] "strict" ipv4 reassembly
From: Nivedita Singhvi @ 2005-05-18 22:39 UTC (permalink / raw)
To: David Stevens; +Cc: Herbert Xu, netdev, netdev-bounce, rick.jones2, Thomas Graf
In-Reply-To: <OFD80D42F2.31DFC921-ON88257005.007ABBCD-88257005.007B23EA@us.ibm.com>
David Stevens wrote:
> netdev-bounce@oss.sgi.com wrote on 05/18/2005 02:46:54 PM:
>
>
>>Thomas Graf <tgraf@suug.ch> wrote:
>>
>>>Wild thought: We could introduce a new ip option stating that the id
>>>generator uses a serial approach which would give us the possibility
>>>to measure the absolute distance and resolve this issue in a perfect
>>>matter for everyone supporting this extension. ;->
>
>
>>Well Linux does that anyway (apart from Suse) so all we need to do
>>is to tell everyone doing NFS over gigabit to use Linux :)
>
>
> If you're going to add an IP option, you can eliminate the
> problem entirely. Just add an "extended IP ID" IP option and give
> it as many bits as you want-- make that the high order of an n+16-bit
> IP ID.
> The IP timestamp option, if done per frag and required to be
> the same for all frags, could be used in this way, since you
> presumably won't wrap without incrementing that by at least 1. :-)
>
> +-DLS
Whatever happened to UDP Path MTU? While we're at this, can't
we start kicking some path-MTU-broken butt?
thanks,
Nivedita
^ permalink raw reply
* Re: [RFC/PATCH] "strict" ipv4 reassembly
From: David Stevens @ 2005-05-18 22:24 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev, netdev-bounce, rick.jones2, Thomas Graf
In-Reply-To: <E1DYWNS-0004ju-00@gondolin.me.apana.org.au>
netdev-bounce@oss.sgi.com wrote on 05/18/2005 02:46:54 PM:
> Thomas Graf <tgraf@suug.ch> wrote:
> >
> > Wild thought: We could introduce a new ip option stating that the id
> > generator uses a serial approach which would give us the possibility
> > to measure the absolute distance and resolve this issue in a perfect
> > matter for everyone supporting this extension. ;->
> Well Linux does that anyway (apart from Suse) so all we need to do
> is to tell everyone doing NFS over gigabit to use Linux :)
If you're going to add an IP option, you can eliminate the
problem entirely. Just add an "extended IP ID" IP option and give
it as many bits as you want-- make that the high order of an n+16-bit
IP ID.
The IP timestamp option, if done per frag and required to be
the same for all frags, could be used in this way, since you
presumably won't wrap without incrementing that by at least 1. :-)
+-DLS
^ permalink raw reply
* igmp snooping?
From: Lennert Buytenhek @ 2005-05-18 22:14 UTC (permalink / raw)
To: netdev
Hi,
Is someone working on igmp snooping (and/or active discovery) for
bridging yet? I currently have a need for this, so if noone is
working on it yet, I'll probably give it a go myself.
AFAICS, for the kernel part:
- Add capability to add/modify/delete multicast (ethernet) addresses
in the forwarding database. Each multicast fdb entry contains a port
bitmask of ports that are interested in this address.
- Lookup multicast addresses in the forwarding path, instead of flooding
every packet.
- Policy decision on whether to drop or flood traffic for multicast
addresses that have no corresponding fdb entry.
- Add capability for userland to 'steal' IGMP packets. (I.e. to be able
to prevent them from being forwarded.)
And some userspace daemon that implements the necessary bits.
Ideas?
cheers,
Lennert
^ permalink raw reply
* ETH_P_ALL and "NIT"
From: Atkinson Stephen-G19998 @ 2005-05-18 21:55 UTC (permalink / raw)
To: netdev
I would like to be able to receive all packets (regardless of type) on a
given net_device. It seems the way to do this would be to use ETH_P_ALL
however, ETH_P_ALL has two meanings, 1) receive all packets and 2) behave
as a "NIT" (Network Interface Tap?). The NIT functionality causes packets
transmitted on the net_device in question to be "received" by the ETH_P_ALL
socket, unless the packet was sent by that socket.
I have a need to receive all incoming packets on a net_device however, for
my needs receiving transmitted packets is an undesirable side effect. So,
I'd like to propose a new ethernet type (ETH_P_ALL_NO_NIT perhaps) which
would behave like ETH_P_ALL without NIT.
Comments? Does this sound reasonable? If so I'll submit a patch.
Thanks,
steve atkinson
^ permalink raw reply
* Re: [RFC/PATCH] "strict" ipv4 reassembly
From: Herbert Xu @ 2005-05-18 21:46 UTC (permalink / raw)
To: Thomas Graf; +Cc: rick.jones2, netdev
In-Reply-To: <20050518174454.GD15391@postel.suug.ch>
Thomas Graf <tgraf@suug.ch> wrote:
>
> Wild thought: We could introduce a new ip option stating that the id
> generator uses a serial approach which would give us the possibility
> to measure the absolute distance and resolve this issue in a perfect
> matter for everyone supporting this extension. ;->
Well Linux does that anyway (apart from Suse) so all we need to do
is to tell everyone doing NFS over gigabit to use Linux :)
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [RFC/PATCH] "strict" ipv4 reassembly
From: Herbert Xu @ 2005-05-18 21:45 UTC (permalink / raw)
To: Rick Jones; +Cc: netdev
In-Reply-To: <428B6B72.5010407@hp.com>
Rick Jones <rick.jones2@hp.com> wrote:
> If we ass-u-me that the sender is indeed using a random IP ID assignment
> mechanism, 30000 is probably too many. There are only 65536 possible ID's, and
> if we "choose" 30000 of them there will undoubtedly be many duplicated. Someone
> who didn't fall asleep too often in ProbStats (unlike myself) can probably tell
> us just how many.
IMHO hosts using purely random IDs all the time are fundamentally broken
for applications such as NFS over UDP over gigabit. However, in order
to handle such hosts we should make this threshold configurable and
then those who need it can set it to a value like 600 which gives a
collision probability with the first fragment of just less than 1%.
> Also, I think the count has to be _any_ IP datagram on that src/dst pair,
> fragmented or not. Someone else pointed-out the possiblity of sending use one
You might be there. However, we should keep in mind that we're not
trying to come up with a perfect solution to the IP fragmentation
problem. All we need is something that's good enough to deal with
usages similar to NFS over UDP over gigabit.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: 2.6.12-rc4-mm2 - sleeping function called from invalid context at mm/slab.c:2502
From: Herbert Xu @ 2005-05-18 21:29 UTC (permalink / raw)
To: David Woodhouse
Cc: Linux Audit Discussion, netdev, David S. Miller, linux-kernel
In-Reply-To: <1116438756.25594.76.camel@localhost.localdomain>
On Wed, May 18, 2005 at 06:52:35PM +0100, David Woodhouse wrote:
>
> I've reverted your recent change to put audit messages directly into
> skbs "in order to eliminate the extra copy", on the basis that it
> blatantly wasn't having that effect anyway. Now we copy from the
> audit_buffer into an optimally-sized skb which netlink_trim() won't have
> to mangle. I've also removed the skb_get() immediately before
> netlink_send() which always made me unhappy.
Even if the audit code is never going to call netlink_unicast with
spin locks held, we simply cannot assume that for all current and
future users of netlink_unicast.
As a consequence we can't use gfp_any() in netlink_unicast.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] NUMA aware allocation of transmit and receive buffers for e1000
From: Andrew Morton @ 2005-05-18 20:42 UTC (permalink / raw)
To: Ganesh Venkatesan; +Cc: christoph, davem, linux-kernel, netdev, shai
In-Reply-To: <5fc59ff305051808558f1ce59@mail.gmail.com>
Ganesh Venkatesan <ganesh.venkatesan@gmail.com> wrote:
>
> On 5/17/05, Andrew Morton <akpm@osdl.org> wrote:
> > I think the e1000 driver is being a bit insane there. I figure that
> Do you mean insane to use vmalloc?
>
> > sizeof(struct e1000_buffer) is 28 on 64-bit, so even with 4k pagesize we'll
> > always succeed in being able to support a 32k/32 = 1024-entry Tx ring.
> >
> > Is there any real-world reason for wanting larger ring sizes than that?
> >
> >
> We have had cases where allocation of 32K of memory (via kmalloc) fails.
>
Are you sure? The current page allocator will infinitely loop until
success for <=32k GFP_KERNEL allocations - the only way it can fail is if
the calling process gets oom-killed.
^ permalink raw reply
* Re: [PATCH] Super TSO
From: David S. Miller @ 2005-05-18 19:57 UTC (permalink / raw)
To: ak; +Cc: netdev
In-Reply-To: <m1fywk645i.fsf@muc.de>
From: Andi Kleen <ak@muc.de>
Date: Wed, 18 May 2005 15:43:21 +0200
> > @@ -674,59 +653,274 @@ unsigned int tcp_sync_mss(struct sock *s
> > * cannot be large. However, taking into account rare use of URG, this
> > * is not a big flaw.
> > */
> > +static inline u32 compute_xmit_cache(u32 mss, int sacks, int tso_enabled)
> > +{
> > + u32 ret = (mss << 16) | sacks;
>
> 16bit MSS? How does that deal with jumbopackets on IPv6?
> While the MSS option is also 16bit it is legal to construct bigger
> datagrams when no MSS option was exchanged.
It doesn't, and neither does the existing code. I know it needs
to be fixed, thanks for reminding me.
^ permalink raw reply
* Du wirst ausspioniert ....!
From: gregl @ 2005-05-18 19:19 UTC (permalink / raw)
To: esmtp
und weisst es nicht einmal:
http://www.heise.de/newsticker/meldung/58003
http://www.heise.de/newsticker/meldung/59304
http://www.heise.de/newsticker/meldung/58311
http://www.heise.de/newsticker/meldung/58351
^ permalink raw reply
* Re: 2.6.12-rc4-mm2 - sleeping function called from invalid context at mm/slab.c:2502
From: David Woodhouse @ 2005-05-18 17:52 UTC (permalink / raw)
To: Linux Audit Discussion; +Cc: Herbert Xu, netdev, David S. Miller, linux-kernel
In-Reply-To: <20050518170033.GT27549@shell0.pdx.osdl.net>
On Wed, 2005-05-18 at 10:00 -0700, Chris Wright wrote:
> * Herbert Xu (herbert@gondor.apana.org.au) wrote:
> > Guys, please CC netdev on issues like this.
>
> Sorry Herbert, we hadn't yet concluded that it's not an issue that we
> need to resolve within audit.
I suspect that it _is_ an issue we can resolve entirely within audit
code. See the patch I posted half an hour or so ago to the linux-audit
list. If we agree on that approach, I'll do the equivalent for the git
tree either later this evening or tomorrow.
I've reverted your recent change to put audit messages directly into
skbs "in order to eliminate the extra copy", on the basis that it
blatantly wasn't having that effect anyway. Now we copy from the
audit_buffer into an optimally-sized skb which netlink_trim() won't have
to mangle. I've also removed the skb_get() immediately before
netlink_send() which always made me unhappy.
--
dwmw2
^ permalink raw reply
* Re: [RFC/PATCH] "strict" ipv4 reassembly
From: Thomas Graf @ 2005-05-18 17:44 UTC (permalink / raw)
To: Rick Jones; +Cc: netdev
In-Reply-To: <20050518174010.GC15391@postel.suug.ch>
* Thomas Graf <20050518174010.GC15391@postel.suug.ch> 2005-05-18 19:40
> In a perfect world without any randomly generated ids we could measure
> the absolute distance even without being aware of all ids, it might even
> be possible to try and differ between random and serial id sequences
> and optimize a bit there but in the end we have to find a good
> compromise for the random case anyway. Worth some experimentation I guess.
Wild thought: We could introduce a new ip option stating that the id
generator uses a serial approach which would give us the possibility
to measure the absolute distance and resolve this issue in a perfect
matter for everyone supporting this extension. ;->
^ permalink raw reply
* [patch 2.6.12-rc4 1/1] tulip: add return to ULI526X clause in tulip_mdio_write
From: John W. Linville @ 2005-05-18 17:41 UTC (permalink / raw)
To: netdev; +Cc: jgarzik, Clear.Zhang
The 'if' clause for ULI526X in tulip_mdio_write allows for
spin_unlock_irqrestore to be called twice for tp->mii_lock. I believe
this is caused by the unintentional omission of a return at the end
of that clause. This patch adds that return.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
I'm copying Clear Zhang on this. As the author of the patch that
added this code, he should know whether or not my intuitive fix is
actually correct... :-)
drivers/net/tulip/media.c | 1 +
1 files changed, 1 insertion(+)
--- linux-2.6.12-rc4/drivers/net/tulip/media.c.orig 2005-05-18 09:19:07.392564077 -0400
+++ linux-2.6.12-rc4/drivers/net/tulip/media.c 2005-05-18 09:22:47.107779100 -0400
@@ -174,6 +174,7 @@ void tulip_mdio_write(struct net_device
break;
}
spin_unlock_irqrestore(&tp->mii_lock, flags);
+ return;
}
/* Establish sync by sending 32 logic ones. */
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: [RFC/PATCH] "strict" ipv4 reassembly
From: Thomas Graf @ 2005-05-18 17:40 UTC (permalink / raw)
To: Rick Jones; +Cc: netdev
In-Reply-To: <428B6B72.5010407@hp.com>
* Rick Jones <428B6B72.5010407@hp.com> 2005-05-18 09:21
> If we ass-u-me that the sender is indeed using a random IP ID assignment
> mechanism, 30000 is probably too many. There are only 65536 possible ID's,
> and if we "choose" 30000 of them there will undoubtedly be many duplicated.
> Someone who didn't fall asleep too often in ProbStats (unlike myself) can
> probably tell us just how many.
I can't come up with a specific number but some thoughts, the upper
limit of the number can be described as a probability of the complete
id space := P_id_space * P_visible
...where
P_id_space := size of effective id space, 1.0 for counters, 0.9-1.0 for
good random schemes.
P_visible := how many fragments do we actually see of the effective id space,
can be described as P_loss + P_scope
P_loss := probability of lost fragment-ids
P_scope := probability of complete view over P_visible, 1.0 if we're the
only receiver, decreases with every additional host we share
the sender's id space with. Also depends on the ration every
receiver sees.
P_id_space and P_loss can be disregarded but P_scope is hard to determine,
the value can range from nearly zero to 1.0 so we can be optimistic and
chose 0.5 or be paranoid and define it as a very small value. But what is
small? F.e. 0.1 would give us a value around 6K which is nothing on a gbit
link at 40kpps on average. I think there isn't even a big difference between
3K and 30K, both border cases we're worrying about can happen with both
limits.
In a perfect world without any randomly generated ids we could measure
the absolute distance even without being aware of all ids, it might even
be possible to try and differ between random and serial id sequences
and optimize a bit there but in the end we have to find a good
compromise for the random case anyway. Worth some experimentation I guess.
> Also, I think the count has to be _any_ IP datagram on that src/dst pair,
> fragmented or not. Someone else pointed-out the possiblity of sending use
> one fragmetned datagram, then 64K to someone else - well, those 64K to
> someone else could just as easily be 64K non-fragmented IP datagrams to us,
> so it seems for a measure of "out of orderness liklihood" we need to
> include non-fragmented IP datagrams.
Sure, I took herbert's "fragments" as "fragment ids", i.e. the per
fragment counter being the distance of different ids between the arrival
of the fragment and the current position.
^ permalink raw reply
* Re: 2.6.12-rc4-mm2 - sleeping function called from invalid context at mm/slab.c:2502
From: Chris Wright @ 2005-05-18 17:00 UTC (permalink / raw)
To: Herbert Xu
Cc: David S. Miller, Linux Audit Discussion, linux-kernel, netdev,
Chris Wright
In-Reply-To: <20050518083002.GA30689@gondor.apana.org.au>
* Herbert Xu (herbert@gondor.apana.org.au) wrote:
> Guys, please CC netdev on issues like this.
Sorry Herbert, we hadn't yet concluded that it's not an issue that we
need to resolve within audit.
> On Tue, May 17, 2005 at 05:43:00PM +0000, Chris Wright wrote:
> >
> > This has some issues w.r.t. truesize and socket buffer space. The trim
> > is done to keep accounting sane, so we'd either have to trim ourselves
> > or take into account the change in size. And ultimately, we'd still get
> > trimmed by netlink, so the GFP issue is still there. Ideally, gfp_any()
> > would really be _any_
>
> The trimming is completely optional. That is, if the allocation fails
> nothing bad will happen. So the solution is to simply use GFP_ATOMIC.
Well, it does more pressure on atomic pool (for those cases that
GFP_KERNEL would have sufficed).
thanks,
-chris
^ permalink raw reply
* Re: [RFC/PATCH] "strict" ipv4 reassembly
From: Rick Jones @ 2005-05-18 16:21 UTC (permalink / raw)
To: netdev
In-Reply-To: <20050518013712.GH13748@postel.suug.ch>
If we ass-u-me that the sender is indeed using a random IP ID assignment
mechanism, 30000 is probably too many. There are only 65536 possible ID's, and
if we "choose" 30000 of them there will undoubtedly be many duplicated. Someone
who didn't fall asleep too often in ProbStats (unlike myself) can probably tell
us just how many.
Also, I think the count has to be _any_ IP datagram on that src/dst pair,
fragmented or not. Someone else pointed-out the possiblity of sending use one
fragmetned datagram, then 64K to someone else - well, those 64K to someone else
could just as easily be 64K non-fragmented IP datagrams to us, so it seems for a
measure of "out of orderness liklihood" we need to include non-fragmented IP
datagrams.
The thought of having to do added accounting on a non-fragmented datagram seems
unpleasant though.
rick jones
^ permalink raw reply
* Re: [PATCH] NUMA aware allocation of transmit and receive buffers for e1000
From: Ganesh Venkatesan @ 2005-05-18 15:55 UTC (permalink / raw)
To: Andrew Morton; +Cc: Christoph Lameter, davem, linux-kernel, netdev, shai
In-Reply-To: <20050517215845.2f87be2f.akpm@osdl.org>
On 5/17/05, Andrew Morton <akpm@osdl.org> wrote:
> I think the e1000 driver is being a bit insane there. I figure that
Do you mean insane to use vmalloc?
> sizeof(struct e1000_buffer) is 28 on 64-bit, so even with 4k pagesize we'll
> always succeed in being able to support a 32k/32 = 1024-entry Tx ring.
>
> Is there any real-world reason for wanting larger ring sizes than that?
>
>
We have had cases where allocation of 32K of memory (via kmalloc) fails.
ganesh.
^ permalink raw reply
* Re: [PATCH] TSO Reloaded
From: John Heffner @ 2005-05-18 13:48 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
In-Reply-To: <20050517.225944.92583479.davem@davemloft.net>
On May 18, 2005, at 1:59 AM, David S. Miller wrote:
>
> Thanks for the data.
>
> How long are your transfers? Just curious.
I was actually measuring 10 second intervals in the middle of a long
running flow.
-John
^ permalink raw reply
* Re: [PATCH] Super TSO
From: Andi Kleen @ 2005-05-18 13:43 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
In-Reply-To: <20050517.192416.108741581.davem@davemloft.net>
"David S. Miller" <davem@davemloft.net> writes:
> I did some cross-continent (San Francisco --> east coast of US)
> transfers to make sure TSO stays on when packet drops occur and that
> performance doesn't suffer compared to TSO being off. It all looks
> fine so far.
It would be interesting to see what happens with moderate packet loss
(= e.g. conditions handled by fast retransmit). That would
lead to occasional "bubbles" in the pipeline. How long would
your algorithm need to refill it then? I suppose this is a common
case on internet servers.
>
> There were many bugs discovered along the way. For example, the
> I moved all of the "should we send" logic privately into the file
> net/ipv4/tcp_output.c, and I am sure there are many simplifications
Thanks that was long overdue, thanks. tcp.h still has too much
inline code though :/
And congratulations for getting rid of the "if() from hell"
in the send check.
> possible. There are several spurious tcp_current_mss() calls scattered
It does far too much work for the common cases too. Similar
is true for the ACK logic in the input path. I think quite
a few cycles could be saved here (although it probably doesn't matter
much anymore on modern boxes because they don't result in cache misses,
so any improvements might end up in the noise)
> @@ -674,59 +653,274 @@ unsigned int tcp_sync_mss(struct sock *s
> * cannot be large. However, taking into account rare use of URG, this
> * is not a big flaw.
> */
> +static inline u32 compute_xmit_cache(u32 mss, int sacks, int tso_enabled)
> +{
> + u32 ret = (mss << 16) | sacks;
16bit MSS? How does that deal with jumbopackets on IPv6?
While the MSS option is also 16bit it is legal to construct bigger
datagrams when no MSS option was exchanged.
-Andi
^ permalink raw reply
* Re: [PATCH] NUMA aware allocation of transmit and receive buffers for e1000
From: Andi Kleen @ 2005-05-18 13:28 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, akpm
In-Reply-To: <428AF378.5020109@cosmosbay.com>
Eric Dumazet <dada1@cosmosbay.com> writes:
> Related question, is pci_alloc_consistent() already NUMA aware ?
It depends on the architecture. On x86-64 it has been for a long time.
I believe IA64 also got it recently.
-Andi
^ permalink raw reply
* Re: [PATCH] NUMA aware allocation of transmit and receive buffers for e1000
From: Andi Kleen @ 2005-05-18 13:19 UTC (permalink / raw)
To: Christoph Lameter; +Cc: akpm, linux-kernel, netdev, shai
In-Reply-To: <Pine.LNX.4.62.0505172125210.22920@graphe.net>
Christoph Lameter <christoph@lameter.com> writes:
> On Tue, 17 May 2005, David S. Miller wrote:
>
>> > Because physically contiguous memory is usually better than virtually
>> > contiguous memory? Any reason that physically contiguous memory will
>> > break the driver?
>>
>> The issue is whether size can end up being too large for
>> kmalloc() to satisfy, whereas vmalloc() would be able to
>> handle it.
>
> Oww.. We need a NUMA aware vmalloc for this?
You can do that already by just changing process NUMA policy temporarily
while calling vmalloc.
-Andi
^ permalink raw reply
* Re: [RFC/PATCH] "strict" ipv4 reassembly
From: Thomas Graf @ 2005-05-18 12:24 UTC (permalink / raw)
To: Herbert Xu; +Cc: David S. Miller, akepner, netdev
In-Reply-To: <20050518114030.GA16993@gondor.apana.org.au>
* Herbert Xu <20050518114030.GA16993@gondor.apana.org.au> 2005-05-18 21:40
> On Wed, May 18, 2005 at 01:30:30PM +0200, Thomas Graf wrote:
> >
> > > I think it's big enough. If it isn't it means that somebody
> > > has reordered the packets by 30000 which I find hard to
> > > believe :)
> >
> > I was thinking about some kind of nfs server with huge recv
> > buffers and increased limits receiving at 50kpps experiencing
> > a delayed fragment once in a while. Definitely a rare case
> > but not impossible ;->
>
> The worst that can happen if 30000 is too low is that we drop
> a packet when we shouldn't. IMHO if a single host sends us an
> incomplete packet, followed by 30000 unrelated fragments, and
> finally a fragment of the original packet, then it is only
> fair for us to drop that packet.
Argueable but I generally agree.
> OTOH if you're arguing that 30000 is too high then you might have
> a point. However, in that respect it cannot be any worse than
> what we have now which is essentially unlimited.
It's definitely better than what we have now, if the sender
uses a per route or even per interface counter we're on the
losing side anyway but if there are any gbit capable oses present
which do that then it's really their problem. Not sure if it
is small enough for randomly generated ids though.
Anyways, I think that the assumption that at least 50% of the
id space is actually used by the sender and seen by the receiver
is fair enough.
^ permalink raw reply
* Re: [PATCH] reduce stack usage for arlan
From: Jörn Engel @ 2005-05-18 12:20 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev
In-Reply-To: <428811FB.1050308@pobox.com>
On Sun, 15 May 2005 23:22:35 -0400, Jeff Garzik wrote:
> Jörn Engel wrote:
> >Jean Tourrilhes indicated that this driver is currently unmaintained.
> >Jeff, do you want this patch?
>
> > #define SARLSTR(var,nn) {\
> >- char tmpStr[400];\
> >+ char tmpStr[50];\
> > int tmpLn = nn;\
> >- if (nn > 399 ) tmpLn = 399; \
> >+ BUG_ON(tmpLn > 49);\
>
> I'm uncomfortable with arbitrarily lowering the string size, even if it
> does include a BUG_ON()...
Here are all invocations of the macro in question:
SARLSTR(textRegion, 48);
SARLSTR(name, 16);
Still uncomfortable?
Jörn
--
Those who come seeking peace without a treaty are plotting.
-- Sun Tzu
^ permalink raw reply
* Re: [RFC/PATCH] "strict" ipv4 reassembly
From: Herbert Xu @ 2005-05-18 11:40 UTC (permalink / raw)
To: Thomas Graf; +Cc: David S. Miller, akepner, netdev
In-Reply-To: <20050518113030.GA15391@postel.suug.ch>
On Wed, May 18, 2005 at 01:30:30PM +0200, Thomas Graf wrote:
>
> > I think it's big enough. If it isn't it means that somebody
> > has reordered the packets by 30000 which I find hard to
> > believe :)
>
> I was thinking about some kind of nfs server with huge recv
> buffers and increased limits receiving at 50kpps experiencing
> a delayed fragment once in a while. Definitely a rare case
> but not impossible ;->
The worst that can happen if 30000 is too low is that we drop
a packet when we shouldn't. IMHO if a single host sends us an
incomplete packet, followed by 30000 unrelated fragments, and
finally a fragment of the original packet, then it is only
fair for us to drop that packet.
OTOH if you're arguing that 30000 is too high then you might have
a point. However, in that respect it cannot be any worse than
what we have now which is essentially unlimited.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [RFC/PATCH] "strict" ipv4 reassembly
From: Thomas Graf @ 2005-05-18 11:30 UTC (permalink / raw)
To: Herbert Xu; +Cc: David S. Miller, akepner, netdev
In-Reply-To: <20050518015213.GB28070@gondor.apana.org.au>
* Herbert Xu <20050518015213.GB28070@gondor.apana.org.au> 2005-05-18 11:52
> On Wed, May 18, 2005 at 03:37:12AM +0200, Thomas Graf wrote:
> >
> > OK, I initially thought you would head for a much larger
> > threshold. Not sure if 30000 is large enough for a full
> > scale NFS server though ;-> You conviced me that my idea
>
> I think it's big enough. If it isn't it means that somebody
> has reordered the packets by 30000 which I find hard to
> believe :)
I was thinking about some kind of nfs server with huge recv
buffers and increased limits receiving at 50kpps experiencing
a delayed fragment once in a while. Definitely a rare case
but not impossible ;->
^ 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