[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140116130753.GE7436@order.stressinduktion.org>
Date: Thu, 16 Jan 2014 14:07:53 +0100
From: Hannes Frederic Sowa <hannes@...essinduktion.org>
To: Florent Fourcot <florent.fourcot@...t-bretagne.fr>
Cc: netdev@...r.kernel.org
Subject: Re: [PATCH V2 net-next 1/3] ipv6: add the IPV6_FL_F_REFLECT flag to IPV6_FL_A_GET
On Thu, Jan 16, 2014 at 01:45:18PM +0100, Florent Fourcot wrote:
>
> >> Was there a specific reason you did not use np->flow_label here and just
> >> mirroring the flowlabel from the first packet of the connection for the
> >> whole connection?
> >>
> >> I don't know if it makes a difference, but maybe it was done on purpose?
> >
> > I thought about it and am actually in favor of reusing the flowid from the syn
> > packet so userspace does report correct outgoing flowlabel even in case of
> > strange tcp peer changing it mid-stream.
> >
>
> Actually, the idea was that the remote could changed the flow label
> during the lifetime of a connection.
> I do not have a strong opinion on that, but in a "reflect" mode, I
> except that the last received value will be in used.
Would it make sense to sync the flowlabel if it changes with the socket, so
user space can query the label really used? Otherwise I wouldn't even report
it.
> Second, in case of SYN cookie, is the SYN flow label stored somewhere?
Should then be synced as soon as the cookie is validated. You can test it by
setting tcp_syncookies to 2. It uses syncookies unconditionally then.
Greetings,
Hannes
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists