Re: svn commit: r344099 - head/sys/net

2019-02-22 Thread John Baldwin
On 2/22/19 8:50 AM, Andrew Gallatin wrote: > I think the misunderstanding here is that I think he's not getting the > ifp from the route. > > My recollection is that he is holding the ifps when he enables HW pacing > in BBR. Due to limitations in different NIC hardware, you can only have > N

Re: svn commit: r344099 - head/sys/net

2019-02-22 Thread Andrew Gallatin
I think the misunderstanding here is that I think he's not getting the ifp from the route. My recollection is that he is holding the ifps when he enables HW pacing in BBR. Due to limitations in different NIC hardware, you can only have N different rates, etc. So he goes ahead and allocates

Re: svn commit: r344099 - head/sys/net

2019-02-21 Thread Hans Petter Selasky
Hi, On 2/21/19 7:28 PM, John Baldwin wrote: On 2/21/19 7:29 AM, Randall Stewart wrote: On Feb 13, 2019, at 1:10 PM, John Baldwin wrote: On 2/13/19 10:03 AM, Randall Stewart wrote: oh and one other thing.. It was*not* a random IFP.. it was the IFP to the lagg. I.e. an alloc() was done

Re: svn commit: r344099 - head/sys/net

2019-02-21 Thread John Baldwin
On 2/21/19 7:29 AM, Randall Stewart wrote: > > >> On Feb 13, 2019, at 1:10 PM, John Baldwin wrote: >> >> On 2/13/19 10:03 AM, Randall Stewart wrote: >>> oh and one other thing.. >>> >>> It was *not* a random IFP.. it was the IFP to the lagg. >>> >>> I.e. an alloc() was done to the lagg.. and

Re: svn commit: r344099 - head/sys/net

2019-02-21 Thread Randall Stewart via svn-src-all
> On Feb 13, 2019, at 1:10 PM, John Baldwin wrote: > > On 2/13/19 10:03 AM, Randall Stewart wrote: >> oh and one other thing.. >> >> It was *not* a random IFP.. it was the IFP to the lagg. >> >> I.e. an alloc() was done to the lagg.. and the free was >> done back to the same IFP (that

Re: svn commit: r344099 - head/sys/net

2019-02-13 Thread John Baldwin
On 2/13/19 10:03 AM, Randall Stewart wrote: > oh and one other thing.. > > It was *not* a random IFP.. it was the IFP to the lagg. > > I.e. an alloc() was done to the lagg.. and the free was > done back to the same IFP (that provided the allocate). Yes, that's wrong. Suppose the route changes

Re: svn commit: r344099 - head/sys/net

2019-02-13 Thread Randall Stewart via svn-src-all
oh and one other thing.. It was *not* a random IFP.. it was the IFP to the lagg. I.e. an alloc() was done to the lagg.. and the free was done back to the same IFP (that provided the allocate). R > On Feb 13, 2019, at 1:02 PM, Randall Stewart wrote: > > I disagree. If you define an alloc it

Re: svn commit: r344099 - head/sys/net

2019-02-13 Thread Randall Stewart via svn-src-all
I disagree. If you define an alloc it is only reciprocal that you should define a free. The code in question that hit this was changed (its in a version of rack that has the rate-limit and TLS code).. but I think these things *should* be balanced.. if you provide an Allocate, you should also

Re: svn commit: r344099 - head/sys/net

2019-02-13 Thread John Baldwin
On 2/13/19 6:57 AM, Randall Stewart wrote: > Author: rrs > Date: Wed Feb 13 14:57:59 2019 > New Revision: 344099 > URL: https://svnweb.freebsd.org/changeset/base/344099 > > Log: > This commit adds the missing release mechanism for the > ratelimiting code. The two modules (lagg and vlan) did

svn commit: r344099 - head/sys/net

2019-02-13 Thread Randall Stewart
Author: rrs Date: Wed Feb 13 14:57:59 2019 New Revision: 344099 URL: https://svnweb.freebsd.org/changeset/base/344099 Log: This commit adds the missing release mechanism for the ratelimiting code. The two modules (lagg and vlan) did have allocation routines, and even though they are