Re: dummynet: bandwidth is limited to 2 Gbit/s ?

2019-10-22 Thread Andriy Gapon 
On 25/09/2019 17:09, Luigi Rizzo wrote:
> As others have commented changing the ABI is a no-go.
> However the command structure can be extended:
> - define a new type, say DN_LINK64, and a new struct dn_link64 with a
> 64-bit bw field;
> - modify the kernel to accept the new type in addition to DN_LINK to
> set link speed,
>   and reply with DN_LINK64 for links whose bandwidth cannot be
> represented on 31 bits
>   (these must come from a userland that understands the new format, so
> it is reasonable
>   to reply to queries with those)
> - modify the ipfw libraries to, likewise, understand DN_LINK64 on
> queries, and issue
>   DN_LINK64 when bw requests do not fit on 31 bits (on failure).
> 
> An alternate, hack-ish approach would be to encode high speeds with
> coarse granularity,
> say speed 0x7fnn with n = 0.. 0xe representing speed in
> Mbits/s (so that would give
> you up to 16 Pbit/s) and reserve 0x7fff for the pre-existing
> "2Gbit/s - 1" to avoid breaking
> former userland that may pick that value.

Luigi, and everyone who commented,

thank you very much for your suggestions.
(Un)fortunately, my work decided to use a workaround rather than extending
dummynet, so I won't be working on that.  Sorry.

I am cross-referencing this thread with an oldish bug for the same issue, just
in case: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194453

-- 
Andriy Gapon
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: dummynet: bandwidth is limited to 2 Gbit/s ?

2019-09-25 Thread Michael Sierchio 
On Wed, Sep 25, 2019 at 7:10 AM Luigi Rizzo  wrote:

 > ...
 > An alternate, hack-ish approach would be to encode high speeds with
 > coarse granularity,
 > say speed 0x7fnn with n = 0.. 0xe representing speed in
 > Mbits/s (so that would give
 > you up to 16 Pbit/s) and reserve 0x7fff for the pre-existing
 > "2Gbit/s - 1" to avoid breaking
 > former userland that may pick that value.

That actually sounds like a good approach, hackish or no.
-- 

"Well," Brahmā said, "even after ten thousand explanations, a fool is no
wiser, but an intelligent person requires only two thousand five hundred."

- The Mahābhārata
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: dummynet: bandwidth is limited to 2 Gbit/s ?

2019-09-25 Thread Eugene Grosbein 
On 25.09.2019 20:53, Andrey V. Elsukov wrote:

> On 25.09.2019 16:51, Eugene Grosbein wrote:
>>> Will this break upgrades with freebsd-update? On a major upgrade,
>>> it will first install the new kernel and require a reboot before
>>> you run freebsd-update again to install the rest.
>>
>> So it will run without dummynet pipes (traffic shaping) configured
>> meantime. Is it big deal?
> 
> Note, that if you have ipfw rule with pipe, that does not exist, all
> matched traffic will be dropped. :-)

Nice catch. Maybe we should introduce new sysctl kern.features.dummynet64 knob 
for new kernels only
but teach /sbin/ipfw for all supported branches to check it. So /sbin/ipfw 
would refuse to process
any dummynet-related rules if knob is present and the binary has no 64-bit 
dummynet support.


___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: dummynet: bandwidth is limited to 2 Gbit/s ?

2019-09-25 Thread Luigi Rizzo 
On Mon, Sep 23, 2019 at 10:43 PM Andriy Gapon  wrote:
>
>
> It seems that the userland component of ipfw/dummynet uses int for the 
> bandwidth
> represented in bit/s.  Also, int is used for passing that value from the
> userland to the kernel.
>
> What would be the best way to extend this?
> Just use a larger type?
> Or maybe add another field to try to preserve KBI backward compatibility?

As others have commented changing the ABI is a no-go.
However the command structure can be extended:
- define a new type, say DN_LINK64, and a new struct dn_link64 with a
64-bit bw field;
- modify the kernel to accept the new type in addition to DN_LINK to
set link speed,
  and reply with DN_LINK64 for links whose bandwidth cannot be
represented on 31 bits
  (these must come from a userland that understands the new format, so
it is reasonable
  to reply to queries with those)
- modify the ipfw libraries to, likewise, understand DN_LINK64 on
queries, and issue
  DN_LINK64 when bw requests do not fit on 31 bits (on failure).

An alternate, hack-ish approach would be to encode high speeds with
coarse granularity,
say speed 0x7fnn with n = 0.. 0xe representing speed in
Mbits/s (so that would give
you up to 16 Pbit/s) and reserve 0x7fff for the pre-existing
"2Gbit/s - 1" to avoid breaking
former userland that may pick that value.

cheers
luigi
that uses an extended field size for length.
One thing that could be done is _extend_ the ABI
>
> Thank you.
> --
> Andriy Gapon
> ___
> freebsd-net@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"



-- 
-+---
 Prof. Luigi RIZZO, ri...@iet.unipi.it  . Dip. di Ing. dell'Informazione
 http://www.iet.unipi.it/~luigi/. Universita` di Pisa
 TEL  +39-050-2217533   . via Diotisalvi 2
 Mobile   +39-338-6809875   . 56122 PISA (Italy)
-+---
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: dummynet: bandwidth is limited to 2 Gbit/s ?

2019-09-25 Thread Andrey V. Elsukov 
On 25.09.2019 16:51, Eugene Grosbein wrote:
>> Will this break upgrades with freebsd-update? On a major upgrade,
>> it will first install the new kernel and require a reboot before
>> you run freebsd-update again to install the rest.
> 
> So it will run without dummynet pipes (traffic shaping) configured
> meantime. Is it big deal?

Note, that if you have ipfw rule with pipe, that does not exist, all
matched traffic will be dropped. :-)

-- 
WBR, Andrey V. Elsukov



signature.asc
Description: OpenPGP digital signature

Re: dummynet: bandwidth is limited to 2 Gbit/s ?

2019-09-25 Thread Eugene Grosbein 
On 25.09.2019 17:27, John Hay wrote:
> 
> 
> On Wed, 25 Sep 2019 at 11:16, Eugene Grosbein  > wrote:
> 
> On 25.09.2019 05:19, Rodney W. Grimes wrote:
> 
> >> AFAIK, we never had any public ABI or stable KBI interface announced 
> to userland or in-kernel consumers
> >> and had no consumers of dummynet other than ipfw(8) binary. Just 
> increase type.
> >
> > Any attempt to mfc this would break KABI/userland and that is never
> > a good thing to do.  It may not be a public ABI, but it is an ABI,
> > and stability of that and backwards compatibility are always a good
> > thing to strive for.
> 
> Agreed. So, no MFC for this.
> 
> 
> Will this break upgrades with freebsd-update? On a major upgrade, it will 
> first install the new kernel and require a reboot before you run 
> freebsd-update again to install the rest.

So it will run without dummynet pipes (traffic shaping) configured meantime. Is 
it big deal?

___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: dummynet: bandwidth is limited to 2 Gbit/s ?

2019-09-25 Thread Andrey V. Elsukov 
On 24.09.2019 08:42, Andriy Gapon wrote:
> 
> It seems that the userland component of ipfw/dummynet uses int for the 
> bandwidth
> represented in bit/s.  Also, int is used for passing that value from the
> userland to the kernel.
> 
> What would be the best way to extend this?
> Just use a larger type?
> Or maybe add another field to try to preserve KBI backward compatibility?

There is yet another problem, that you need to keep in mind.
Some people may use old ipfw(8) binaries inside jails, that can be
executed on modern host system. So, if you will break KBI, then such
jails will stop work.

-- 
WBR, Andrey V. Elsukov



signature.asc
Description: OpenPGP digital signature

Re: dummynet: bandwidth is limited to 2 Gbit/s ?

2019-09-25 Thread Andriy Gapon 
On 25/09/2019 13:27, John Hay wrote:
> 
> 
> On Wed, 25 Sep 2019 at 11:16, Eugene Grosbein  > wrote:
> 
> On 25.09.2019 05:19, Rodney W. Grimes wrote:
> 
> >> AFAIK, we never had any public ABI or stable KBI interface announced to
> userland or in-kernel consumers
> >> and had no consumers of dummynet other than ipfw(8) binary. Just 
> increase
> type.
> >
> > Any attempt to mfc this would break KABI/userland and that is never
> > a good thing to do.  It may not be a public ABI, but it is an ABI,
> > and stability of that and backwards compatibility are always a good
> > thing to strive for.
> 
> Agreed. So, no MFC for this.
> 
> 
> Will this break upgrades with freebsd-update? On a major upgrade, it will 
> first
> install the new kernel and require a reboot before you run freebsd-update 
> again
> to install the rest.

I am also concerned about this.

But isn't the procedure is to reboot to single-user mode?
Then, the access to the console is required and rc scripts, including firewall
configuration, are not run anyway.


-- 
Andriy Gapon
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: dummynet: bandwidth is limited to 2 Gbit/s ?

2019-09-25 Thread John Hay 
On Wed, 25 Sep 2019 at 11:16, Eugene Grosbein  wrote:

> On 25.09.2019 05:19, Rodney W. Grimes wrote:
>
> >> AFAIK, we never had any public ABI or stable KBI interface announced to
> userland or in-kernel consumers
> >> and had no consumers of dummynet other than ipfw(8) binary. Just
> increase type.
> >
> > Any attempt to mfc this would break KABI/userland and that is never
> > a good thing to do.  It may not be a public ABI, but it is an ABI,
> > and stability of that and backwards compatibility are always a good
> > thing to strive for.
>
> Agreed. So, no MFC for this.
>

Will this break upgrades with freebsd-update? On a major upgrade, it will
first install the new kernel and require a reboot before you run
freebsd-update again to install the rest.

Regards

John
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: dummynet: bandwidth is limited to 2 Gbit/s ?

2019-09-25 Thread Eugene Grosbein 
On 25.09.2019 05:19, Rodney W. Grimes wrote:

>> AFAIK, we never had any public ABI or stable KBI interface announced to 
>> userland or in-kernel consumers
>> and had no consumers of dummynet other than ipfw(8) binary. Just increase 
>> type.
> 
> Any attempt to mfc this would break KABI/userland and that is never
> a good thing to do.  It may not be a public ABI, but it is an ABI,
> and stability of that and backwards compatibility are always a good
> thing to strive for.

Agreed. So, no MFC for this.


___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: dummynet: bandwidth is limited to 2 Gbit/s ?

2019-09-24 Thread Rodney W. Grimes 
> On 24.09.2019 12:42, Andriy Gapon wrote:
> 
> > It seems that the userland component of ipfw/dummynet uses int for the 
> > bandwidth
> > represented in bit/s.  Also, int is used for passing that value from the
> > userland to the kernel.
> > 
> > What would be the best way to extend this?
> > Just use a larger type?
> > Or maybe add another field to try to preserve KBI backward compatibility?
> > 
> > Thank you.
> 
> AFAIK, we never had any public ABI or stable KBI interface announced to 
> userland or in-kernel consumers
> and had no consumers of dummynet other than ipfw(8) binary. Just increase 
> type.

Any attempt to mfc this would break KABI/userland and that is never
a good thing to do.  It may not be a public ABI, but it is an ABI,
and stability of that and backwards compatibility are always a good
thing to strive for.

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: dummynet: bandwidth is limited to 2 Gbit/s ?

2019-09-24 Thread Eugene Grosbein 
On 24.09.2019 12:42, Andriy Gapon wrote:

> It seems that the userland component of ipfw/dummynet uses int for the 
> bandwidth
> represented in bit/s.  Also, int is used for passing that value from the
> userland to the kernel.
> 
> What would be the best way to extend this?
> Just use a larger type?
> Or maybe add another field to try to preserve KBI backward compatibility?
> 
> Thank you.

AFAIK, we never had any public ABI or stable KBI interface announced to 
userland or in-kernel consumers
and had no consumers of dummynet other than ipfw(8) binary. Just increase type.


___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

dummynet: bandwidth is limited to 2 Gbit/s ?

2019-09-23 Thread Andriy Gapon 


It seems that the userland component of ipfw/dummynet uses int for the bandwidth
represented in bit/s.  Also, int is used for passing that value from the
userland to the kernel.

What would be the best way to extend this?
Just use a larger type?
Or maybe add another field to try to preserve KBI backward compatibility?

Thank you.
-- 
Andriy Gapon
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"