From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Dumazet Subject: Re: [PATCH 2/2] IB/ipoib: fix GRO merge failure for IPoIB originated TCP streams Date: Mon, 30 Jan 2012 09:53:03 +0100 Message-ID: <1327913583.2288.5.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC> References: <4F264A6C.3070706@mellanox.com> <1327910672.2891.12.camel@edumazet-laptop> <20120130081849.GA7848@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Or Gerlitz , Roland Dreier , davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org, linux-rdma , Shlomo Pongratz , netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Herbert Xu Return-path: In-Reply-To: <20120130081849.GA7848-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org> Sender: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: netdev.vger.kernel.org Le lundi 30 janvier 2012 =C3=A0 19:18 +1100, Herbert Xu a =C3=A9crit : > On Mon, Jan 30, 2012 at 09:04:32AM +0100, Eric Dumazet wrote: > > > > Hmm, do we really need to compare ether header, thats the question. >=20 > I think we do. As otherwise macvlan would break. >=20 Thats the theory yes, but practically ? Really, GRO can merge two TCP frames given they match everything needed= , exactly as our TCP stack would do in the end. What could be a normal workload where this mismatch of two different tc= p flows could happen with macvlan or any kind of devices ? If this is an attack, TCP will merge the frames anyway on the same socket. Or should we add checks in TCP stack, in case GRO is off ? -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" i= n the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html