Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 13 Mar 2010 13:53:36 +0000
From:      "Robert N. M. Watson" <rwatson@FreeBSD.org>
To:        Randall Stewart <rrs@lakerest.net>
Cc:        svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org
Subject:   Re: svn commit: r205104 - in head/sys: dev/xen/netback netinet netinet6
Message-ID:  <92C0A9B0-9297-4F56-A6A1-603006423230@FreeBSD.org>
In-Reply-To: <2F4A2F84-4955-49C2-B25E-BB987BC27815@lakerest.net>
References:  <201003122258.o2CMwqDM039077@svn.freebsd.org> <alpine.BSF.2.00.1003131257060.51476@fledge.watson.org> <2F4A2F84-4955-49C2-B25E-BB987BC27815@lakerest.net>

next in thread | previous in thread | raw e-mail | index | archive | help

On Mar 13, 2010, at 1:50 PM, Randall Stewart wrote:

> did not think of that.. we COULD possible do it another way.. a bit =
harder
> but possible.. i.e. have the delayed sack code actually look into
> the mbufs and see if its ipv4 or ipv6.. I thought about doing it
> that way but it takes more cycles ;-o
>=20
> I could refactor that this way if you want... it would mean a few more =
de-ref's and
> looking to see if its a v4 or v6 packet and then doing the proper =
offset...
>=20
> not to bad but awkward ;-0

Well, I think what I was trying to get across more is that this change =
is OK to merge, but only because you were lucky (or, more arguably, =
there is a Makefile bug). So the best advice is to future-proof =
yourself: keep very close tabs on the use of SCTP symbols and =
definitions outside of the core code, especially in modules, and make =
sure you're entirely happy with KPI/KBI exposures from inception.

Robert=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?92C0A9B0-9297-4F56-A6A1-603006423230>