lkml.org 
[lkml]   [2011]   [Jan]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH] new UDPCP Communication Protocol
    From
    Date
    Le samedi 01 janvier 2011 à 22:44 +0100, stefani@seibold.net a écrit :
    > From: Stefani Seibold <stefani@seibold.net>
    >
    > Changelog:
    > 31.12.2010 first proposal
    > 01.01.2011 code cleanup and fixes suggest by Eric Dumazet
    >
    > UDPCP is a communication protocol specified by the Open Base Station
    > Architecture Initiative Special Interest Group (OBSAI SIG). The
    > protocol is based on UDP and is designed to meet the needs of "Mobile
    > Communcation Base Station" internal communications. It is widely used by
    > the major networks infrastructure supplier.
    >
    > The UDPCP communication service supports the following features:
    >
    > -Connectionless communication for serial mode data transfer
    > -Acknowledged and unacknowledged transfer modes
    > -Retransmissions Algorithm
    > -Checksum Algorithm using Adler32
    > -Fragmentation of long messages (disassembly/reassembly) to match to the MTU
    > during transport:
    > -Broadcasting and multicasting messages to multiple peers in unacknowledged
    > transfer mode
    >
    > UDPCP supports application level messages up to 64 KBytes (limited by 16-bit
    > packet data length field). Messages that are longer than the MTU will be
    > fragmented to the MTU.
    >
    > UDPCP provides a reliable transport service that will perform message
    > retransmissions in case transport failures occur.
    >
    > The code is also a nice example how to implement a UDP based protocol as
    > a kernel socket modules.
    >
    > Due the nature of UDPCP which has no sliding windows support, the latency has a
    > huge impact. The perfomance increase by implementing as a kernel module is
    > about the factor 10, because there are no context switches and data packets or
    > ACKs will be handled in the interrupt service.
    >
    > There are no side effects to the network subsystems so i ask for merge it
    > into linux-next. Hope you like it.
    >
    > The patch is against 2.6.37-rc8
    >

    Hi Stefani

    1) Please base your next trys on net-next-2.6 : This is the reference
    for stuff like that. It probably does not matter a lot, but still...


    2) I still see some _irq() variants of spinlock(). Its not necessary in
    network stack at the level you are working (process context, and
    softirqs)

    Please only use _bh() variants, it's enough.

    3) I see UDPLITE references in your code. Are you sure UDPCP protocol
    can really work on top of UDPLITE ? I think not, so please remove dead
    code.

    4) udpcp_release_sock() seems expensive to me. Why not testing
    usk->timeout before releasing sock lock, and save a lock/unlock pair ?

    static inline void udpcp_release_sock(struct sock *sk)
    {
    struct udpcp_sock *usk = udpcp_sk(sk);

    if (usk->timeout)
    udpcp_handle_timeout(sk);
    release_sock(sk);
    }

    5) In udpcp_timeout(), if you find socket is locked by user, you set
    timeout to one and rearm a timer to udpcp_timer(sk, jiffies + 1);

    Why is it needed, since user process is going to handle the timeout
    indication from udpcp_release_sock() ?

    Thanks


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2011-01-01 23:25    [W:0.028 / U:1.248 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site