Hi!
This is looking better!
Structurally though, I'd look at all those places where you only
update tp->newcv and instead of passing in the tp, pass in a pointer
to tp->newcv. That way you're keeping a lid on the scope of the helper
functions - they only get access to as much data as they need so
On Fri, Aug 01, 2014 at 03:19:20PM +0100, Tom Jones wrote:
>
> I have updated the patch to move the new variable introduced with newcwv into
> a
> struct within the tcpcb.
Forgot some files in the diff.
--
Tom | I don't see how we are going to build the dystopian megapoli
@adventur
On Mon, Jun 30, 2014 at 09:53:59PM +0100, Tom Jones wrote:
> On Mon, Jun 30, 2014 at 12:29:44PM -0700, Adrian Chadd wrote:
> > Hi!
> >
> > Cool! Would you mind throwing it into a bugzilla ticket so it's not
> > lost and it can be assigned for some review?
> >
> > http://bugs.freebsd.org/submit/
>
On Mon, Jun 30, 2014 at 12:29:44PM -0700, Adrian Chadd wrote:
> Hi!
>
> Cool! Would you mind throwing it into a bugzilla ticket so it's not
> lost and it can be assigned for some review?
>
> http://bugs.freebsd.org/submit/
Done.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191520
> Is ther
Hi!
Cool! Would you mind throwing it into a bugzilla ticket so it's not
lost and it can be assigned for some review?
http://bugs.freebsd.org/submit/
Is there any benefit in hanging this state off of it as a pointer to
some other struct, rather than having it in the tcpcb? Is it always
going to b
Hello,
Attached is a patch which implements draft-ietf-tcpm-newcwv-06, "Updating TCP
to support Rate-Limited Traffic". The patch is a port of the Linux
implementation by Raffaello Secchi with influence from Aris
Angelogiannopoulos's patch set that was sent to the list earlier this year.
--
Tom