On Wed, Oct 14, 2015 at 3:24 AM, Julian Anastasov wrote:
>
> Hello,
>
> On Wed, 14 Oct 2015, Xin Long wrote:
>
>> commit fe3edf45792a ("ipv4: Remove all RTCF_DIRECTSRC handliing.").
>>
>> Before this commit, we had a tristate:
>> < 0: error
>> 0: ok
>> 1: ok and set RTCF_DIRECTSRC
>>
>> Bu
>
> In addition to what David said and looking at it from a different angle...
> 256 buckets
> may not be enough for someone with a single endpoint and alot of
> associations. You
> will still hit a long chain on INIT and COOKIE-ECHO chunks.
>
> Switching to using rhashtable for association hash
On Tue, Sep 1, 2015 at 6:16 AM, David Miller wrote:
> From: Xin Long
> Date: Tue, 1 Sep 2015 01:44:28 +0800
>
>> @@ -524,18 +524,16 @@ static inline int sctp_assoc_hashfn(struct net *net,
>> __u16 lport, __u16 rport)
>> {
>> int h = (lport << 16) + rport + net_hash_mix(net);
>> h ^
that patch is actually meant for net-next, need to state.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
attachment is the test script above-mentioned.
sctperf.tar.gz
Description: GNU Zip compressed data
hi, Vlad, plz help to ACK this one
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>> So one potential way is to have peer.rwnd and peer.a_rwnd, where
>>> peer.a_rwnd is
>>> the window advertised by peer and peer.rwnd and our estimation based on
>>> peer.a_rwnd.
>>> This way we will always know where we stand.
>>>
>>> Although I am not sure yet if we want to grow the peer
>
> So one potential way is to have peer.rwnd and peer.a_rwnd, where peer.a_rwnd
> is
> the window advertised by peer and peer.rwnd and our estimation based on
> peer.a_rwnd.
> This way we will always know where we stand.
>
> Although I am not sure yet if we want to grow the peer structure any mo
>
> Actually, silently dropping this is _very_ bad. There reason is that you've
> already
> processed the leading chunks and may have potentially queued a response...
> Now, you
> reach the end of the packet and find that the last chunk is partial. You end
> up
> dropping the packet, but stil
>
> No, these are 2 distinct instances. In one instance, the peer is reachable
> and
> is able to communication 0 rwnd state to us. Thus we are being nice and
> granting
> the peer more time to exit the 0 window state.
>
> In the other state, the peer is unreachable and we just happen to hit th
On Thu, Aug 27, 2015 at 5:33 AM, Vlad Yasevich wrote:
> On 08/26/2015 05:03 PM, Xin Long wrote:
>> in sctp_process_asconf(), we get address parameter from the beginning of
>> the addip params. but we never check if it's really there. if the addr
>> param is not there, it still can pass sctp_verify
On Thu, Aug 27, 2015 at 4:59 AM, Marcelo Ricardo Leitner
wrote:
> On Wed, Aug 26, 2015 at 04:42:21PM -0400, Vlad Yasevich wrote:
>> On 08/26/2015 04:35 PM, Xin Long wrote:
>> > in sctp_process_asconf(), we get address parameter from the beginning of
>> > the addip params. but we never check if it'
On Tue, Aug 25, 2015 at 8:39 PM, lucien xin wrote:
>>
>> I think it would be much better to catch this in the validation stage.
>> If an implementation inserts multiple address parameters, we don't really
>> know
>> which one we should be using.
>>
>
>
> I think it would be much better to catch this in the validation stage.
> If an implementation inserts multiple address parameters, we don't really know
> which one we should be using.
>
the params of ASCONF chunk should consist of one *Address Parameter* and one
or more *ASCONF Parameters*. be
>
> Sorry, you can't do that directly without a lot more checks. The parameer
> may be only only partial, or may not be there at all. You'd end up looking
> at wrong mememory.
>
> A better way would be to set the addr_param_seen only when looking at
> the first parameter (addip_hdr.params).
>
I w
On Mon, Jul 27, 2015 at 9:44 PM, Marcelo Ricardo Leitner
wrote:
> On Sat, Jul 25, 2015 at 01:08:08PM +0800, Xin Long wrote:
>> RFC 5061:
>> This is an opaque integer assigned by the sender to identify each
>> request parameter. The receiver of the ASCONF Chunk will copy this
>> 32-bit
On Sat, Jul 25, 2015 at 3:11 AM, Marcelo Ricardo Leitner
wrote:
> On Fri, Jul 24, 2015 at 02:56:29PM +0800, Xin Long wrote:
>> RFC 5061:
>> This is an opaque integer assigned by the sender to identify each
>> request parameter. The receiver of the ASCONF Chunk will copy this
>> 32-bit
17 matches
Mail list logo
