04 Jun, 2016

1 commit

  • SCTP has this pecualiarity that its packets cannot be just segmented to
    (P)MTU. Its chunks must be contained in IP segments, padding respected.
    So we can't just generate a big skb, set gso_size to the fragmentation
    point and deliver it to IP layer.

    This patch takes a different approach. SCTP will now build a skb as it
    would be if it was received using GRO. That is, there will be a cover
    skb with protocol headers and children ones containing the actual
    segments, already segmented to a way that respects SCTP RFCs.

    With that, we can tell skb_segment() to just split based on frag_list,
    trusting its sizes are already in accordance.

    This way SCTP can benefit from GSO and instead of passing several
    packets through the stack, it can pass a single large packet.

    v2:
    - Added support for receiving GSO frames, as requested by Dave Miller.
    - Clear skb->cb if packet is GSO (otherwise it's not used by SCTP)
    - Added heuristics similar to what we have in TCP for not generating
    single GSO packets that fills cwnd.
    v3:
    - consider sctphdr size in skb_gso_transport_seglen()
    - rebased due to 5c7cdf339af5 ("gso: Remove arbitrary checks for
    unsupported GSO")

    Signed-off-by: Marcelo Ricardo Leitner
    Tested-by: Xin Long
    Signed-off-by: David S. Miller

    Marcelo Ricardo Leitner
     

16 Apr, 2016

1 commit

  • This one will implement all the interface of inet_diag, inet_diag_handler.
    which includes sctp_diag_dump, sctp_diag_dump_one and sctp_diag_get_info.

    It will work as a module, and register inet_diag_handler when loading.

    v2->v3:
    - fix the mistake in inet_assoc_attr_size().

    - change inet_diag_msg_laddrs_fill() name to inet_diag_msg_sctpladdrs_fill.

    - change inet_diag_msg_paddrs_fill() name to inet_diag_msg_sctpaddrs_fill.

    - add inet_diag_msg_sctpinfo_fill() to make asoc/ep fill code clearer.

    - add inet_diag_msg_sctpasoc_fill() to make asoc fill code clearer.

    - merge inet_asoc_diag_fill() and inet_ep_diag_fill() to
    inet_sctp_diag_fill().

    - call sctp_diag_get_info() directly, instead by handler, cause the caller
    is in the same file with it.

    - call lock_sock in sctp_tsp_dump_one() to make sure we call get sctp info
    safely.

    - after lock_sock(sk), we should check sk != assoc->base.sk.

    - change mem[SK_MEMINFO_WMEM_ALLOC] to asoc->sndbuf_used for asoc dump when
    asoc->ep->sndbuf_policy is set. don't use INET_DIAG_MEMINFO attr any more.

    Signed-off-by: Xin Long
    Signed-off-by: David S. Miller

    Xin Long
     

09 Jul, 2014

1 commit

  • sctp_init_cmd_seq() and sctp_next_cmd() are only called from one place.
    The call sequence for sctp_add_cmd_sf() is likely to be longer than
    the inlined code.
    With sctp_add_cmd_sf() inlined the compiler can optimise repeated calls.

    Signed-off-by: David Laight
    Signed-off-by: David S. Miller

    David Laight
     

01 May, 2010

1 commit

  • This patch implement sctp association probing module, the module
    will be called sctp_probe.

    This module allows for capturing the changes to SCTP association
    state in response to incoming packets. It is used for debugging
    SCTP congestion control algorithms.

    Usage:
    $ modprobe sctp_probe [full=n] [port=n] [bufsize=n]
    $ cat /proc/net/sctpprobe

    The output format is:
    TIME ASSOC LPORT RPORT MTU RWND UNACK ...

    The output will be like this:
    9.226086 c4064c48 9000 8000 1500 53352 1 *192.168.0.19 1 4380 54784 1252 0 1500
    9.287195 c4064c48 9000 8000 1500 45144 5 *192.168.0.19 1 5880 54784 6500 0 1500
    9.289130 c4064c48 9000 8000 1500 42724 5 *192.168.0.19 1 7380 54784 6500 0 1500
    9.620332 c4064c48 9000 8000 1500 48284 4 *192.168.0.19 1 8880 54784 5200 0 1500
    ......

    Signed-off-by: Wei Yongjun
    Signed-off-by: Vlad Yasevich

    Wei Yongjun
     

19 Jul, 2008

1 commit


29 Jan, 2008

1 commit


11 Oct, 2007

1 commit


17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds