1. 14 3月, 2009 5 次提交
  2. 12 3月, 2009 1 次提交
  3. 10 3月, 2009 2 次提交
  4. 07 3月, 2009 1 次提交
  5. 06 3月, 2009 5 次提交
  6. 05 3月, 2009 3 次提交
  7. 04 3月, 2009 6 次提交
  8. 03 3月, 2009 14 次提交
  9. 02 3月, 2009 3 次提交
    • G
      dccp: Do not let initial option overhead shrink the MPS · 86739fb9
      Gerrit Renker 提交于
      This fixes a problem caused by the overlap of the connection-setup and
      established-state phases of DCCP connections.
      
      During connection setup, the client retransmits Confirm Feature-Negotiation
      options until a response from the server signals that it can move from the
      half-established PARTOPEN into the OPEN state, whereupon the connection is
      fully established on both ends (RFC 4340, 8.1.5).
      
      However, since the client may already send data while it is in the PARTOPEN
      state, consequences arise for the Maximum Packet Size: the problem is that the
      initial option overhead is much higher than for the subsequent established
      phase, as it involves potentially many variable-length list-type options
      (server-priority options, RFC 4340, 6.4).
      
      Applying the standard MPS is insufficient here: especially with larger
      payloads this can lead to annoying, counter-intuitive EMSGSIZE errors.
      
      On the other hand, reducing the MPS available for the established phase by
      the added initial overhead is highly wasteful and inefficient.
      
      The solution chosen therefore is a two-phase strategy:
      
         If the payload length of the DataAck in PARTOPEN is too large, an Ack is sent
         to carry the options, and the feature-negotiation list is then flushed.
      
         This means that the server gets two Acks for one Response. If both Acks get
         lost, it is probably better to restart the connection anyway and devising yet
         another special-case does not seem worth the extra complexity.
      
      The result is a higher utilisation of the available packet space for the data
      transmission phase (established state) of a connection.
      
      The patch (over-)estimates the initial overhead to be 32*4 bytes -- commonly
      seen values were around 90 bytes for initial feature-negotiation options.
      
      It uses sizeof(u32) to mean "aligned units of 4 bytes".
      For consistency, another use of 4-byte alignment is adapted.
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      86739fb9
    • G
      dccp: Minimise header option overhead in setting the MPS · 361a5c1d
      Gerrit Renker 提交于
      This patch resolves a long-standing FIXME to dynamically update the Maximum
      Packet Size depending on actual options usage.
      
      It uses the flags set by the feature-negotiation infrastructure to compute
      the required header option size.
      
      Most options are fixed-size, a notable exception are Ack Vectors (required
      currently only by CCID-2). These can have any length between 3 and 1020
      bytes. As a result of testing, 16 bytes (2 bytes for type/length plus 14 Ack
      Vector cells) have been found to be sufficient for loss-free situations.
      
      There are currently no CCID-specific header options which may appear on data
      packets, thus it is not necessary to define a corresponding CCID field as
      suggested in the old comment.
      
      Further changes:
      ----------------
       Adjusted the type of 'cur_mps' to match the unsigned return type of the
       function.
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      Acked-by: NIan McDonald <ian.mcdonald@jandi.co.nz>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      361a5c1d
    • I
      tcp: get rid of two unnecessary u16s in TCP skb flags copying · 9ce01461
      Ilpo Järvinen 提交于
      I guess these fields were one day 16-bit in the struct but
      nowadays they're just using 8 bits anyway.
      
      This is just a precaution, didn't result any change in my
      case but who knows what all those varying gcc versions &
      options do. I've been told that 16-bit is not so nice with
      some cpus.
      Signed-off-by: NIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9ce01461