Date: Fri, 6 Jun 2014 11:23:29 +0800 From: Sato Kentney <satokentney@gmail.com> To: Luigi Rizzo <rizzo@iet.unipi.it> Cc: bycn82 <bycn82@gmail.com>, "Alexander V. Chernikov" <melifaro@ipfw.ru>, FreeBSD Net <net@freebsd.org> Subject: Re: [CFT]: ipfw named tables / different tabletypes Message-ID: <CAD3kpuWcuZ%2B93c4fRGKoXxg%2ByFxkiDOdhFpG6A-Jv-HtBcJ0CQ@mail.gmail.com> In-Reply-To: <20140605165806.GC81905@onelab2.iet.unipi.it> References: <20140522154740.GA76448@onelab2.iet.unipi.it> <537E2153.1040005@FreeBSD.org> <20140522163812.GA77634@onelab2.iet.unipi.it> <538B2FE5.6070407@FreeBSD.org> <539044E4.1020904@ipfw.ru> <000c01cf80be$41194370$c34bca50$@gmail.com> <20140605134256.GA81234@onelab2.iet.unipi.it> <000001cf80cd$5dc1d9b0$19458d10$@gmail.com> <20140605155402.GA81905@onelab2.iet.unipi.it> <000401cf80d8$ad1bb840$075328c0$@gmail.com> <20140605165806.GC81905@onelab2.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
Your original porpose of pps is good enough for me, it controls packets
number for each second. it is simple and make sence, As a network
administrator, I think if you provide "packets per second" or "packets per
minute" ,that is good enough for 99% percent of users.
Thanks,
Sato K(=E4=BD=90=E8=97=A4=E6=9F=AF=E5=BE=B7)
On Fri, Jun 6, 2014 at 12:58 AM, Luigi Rizzo <rizzo@iet.unipi.it> wrote:
> On Fri, Jun 06, 2014 at 12:10:26AM +0800, bycn82 wrote:
> > Sorry for waste you time to explain it again, I will read the code firs=
t.
> >
> > And the latest patch of `PPS` should be OK, I checked the logic
> carefully this time. I sent it out last weekend.
> >
> > logic as below, PPS actually will be fulfilled using `PPT`,(N packets
> per M ticks).
>
> Bill,
> sorry but even this version has multiple issues -- performance,
> correctness, style.
>
> performance:
> duration_in_ticks and limit do not need to be recomputed
> on every packet, just once when you install the rule.
>
> correctness
> limit should be not lower than the user-specified value,
> so if the equation has the form \lceil{a}{b} \rceil,
> the correct computation using integer arithmetic is
> (a + b - 1)/b and not (a + b/2) / b
>
> You should also check for corner cases, overflows etc.
> I haven't actually checked that the equation you use is
> correct, so a comment explaining why it is would be appropriate.
>
> BTW you have no checks on the input arguments, so you can
> have duration =3D0 and then you have a division by 0 in the kernel.
>
> style
> boring as it might be, we use spaces around keywords and { }
>
> I am also unhappy on the ppt option, because the duration of a tick
> can change across reboots, so this option would give variable
> behaviour. With all sources of uncertainty on packet arrivals
> and when the timer fires to advance 'ticks', there is really
> no point in having PPT to avoid the rounding error with some
> strange values of HZ.
>
>
> Now before you think i am too picky:
> some of the above (style) are trivial issues, but they require
> manual editing of the patch before applying and this is the reason
> many project and people usually bounce patches just because of style
> (the process does not scale otherwise).
> If it were just for that, i would not mind.
>
> But many of the other problems are more serious, and the fact they
> keep coming out after so many iterations suggest me that _you_
> should spend more time reviewing your code before submitting it
> and asking others to find and fix problems.
>
> cheers
> luigi
>
> >
> > + case O_PPT:
> > + case O_PPS:{
> > + ipfw_insn_pps *pps =3D (ipfw_insn_pps *)c=
md;
> > + if(pps->limit=3D=3D0){
> > + int limit,duration_in_ticks;
> > + if(1000/hz > pps->duration){
> > + duration_in_ticks=3D1;
> > + }else{
> > +
> duration_in_ticks=3D(pps->duration * hz +500)/1000;
> > + }
> > + limit=3D(cmd->arg1 *1000 *
> duration_in_ticks + hz * pps->duration/2)/(hz * pps->duration);
> > + pps->limit=3Dlimit;
> > +
> pps->duration_in_ticks=3Dduration_in_ticks;
> > + }
> > +
> if(pps->start_time+pps->duration_in_ticks>=3D ticks){
> > + if(pps->count < pps->limit){
> > + retval =3D IP_FW_PASS;
> > + }else{
> > + retval =3D IP_FW_DENY;
> > + }
> > + pps->count++;
> > + }else{
> > + pps->start_time=3Dticks;
> > + pps->count=3D1;
> > + retval =3D IP_FW_PASS;
> > + }
> > + l =3D 0;
> > + done =3D 1;
> > + break;
> > + }
> _______________________________________________
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAD3kpuWcuZ%2B93c4fRGKoXxg%2ByFxkiDOdhFpG6A-Jv-HtBcJ0CQ>