lkml.org 
[lkml]   [2000]   [Sep]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: networking todo, was Re: Linux-2.4.0-test9-pre2
       Date: Wed, 20 Sep 2000 03:14:10 +0200
    From: "Andi Kleen" <ak@suse.de>

    The ipid handling is still fishy, it will break when you talk to
    more destinations than the inetpeer cache can take (I fixed it in
    my local tree with the appended patch)

    I don't like this change, please work with Alexey on this one.
    Do not assume we are removing the inetpeer cache also, see below.

    Receiver side SMP reordering is still there, but I'm not sure if it is
    fixable (but it'll surely hit people that cannot use Linux senders, I
    just see the reports)

    Reordering is a non-issue for ipv4/ipv6, all of the massive TCP input
    rewrite was strictly about dealing with this. No SMP reordering
    should cause any bogus fast retransmits etc. for example.

    What is the problem? Are you referering to the LAPB/X25 stuff?

    The TCP connect running out of ports problem is still there (I
    fixed it locally, but the changes are probably far too extensive
    for 2.4.x now)

    I think people can change their ip_local_port_range and I really
    consider this a non-issue, at least, it's not a 2.4.x show stopper.

    The TCP ISN computation is not SMP safe.

    "Big deal". So how much effort will you go to to get how much more
    protection and how much of it do we really need? How less secure are
    our TCP ISN's because of this? Not a show-stopper.

    I think you're reading too much tcp-impl :-)

    include/linux/snmp.h is probably still not properly aligned for all
    cache line sizes.

    Read, and reread what Alexey tries to tell you over and over about
    this. It is not meant to be cache line aligned, it is meant to be a
    power of two and nothing more.

    Not a bug.

    UDP recvmsg error handling for csum errors is bogus (fix pending)

    Ok, send me a patch so I can see what the problem is.

    I also would like to remove the inetpeer cache code before 2.4.0, now
    that nobody managed to salvage tw recycling and ipid can do without it.

    I would prefer not to, it seems to be too potentially destabilizing
    for questionable and unknown gain (ie. we don't know if tw recycling
    can be salvaged, so lets not take any changes).

    Later,
    David S. Miller
    davem@redhat.com
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 12:38    [W:0.023 / U:29.812 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site