[RFC] Add support for hardware transmit rate limiting queues [WAS: Add support for changing the flow ID of TCP connections]

2014-08-20 Thread Hans Petter Selasky
Hi, A month has passed since the last e-mail on this topic, and in the meanwhile some new patches have been created and tested: Basically the approach has been changed a little bit: - The creation of hardware transmit rings has been made independent of the TCP stack. This allows firewall

Re: android bsd connectivity tools etc ?

2014-08-20 Thread Jamie Landeg-Jones
Shane Ambler free...@shaneware.biz wrote: da0 at umass-sim1 bus 1 scbus5 target 0 lun 0 da0: Android Adapter 0100 Removable Direct Access SCSI-2 device cd1 at umass-sim1 bus 1 scbus5 target 0 lun 1 cd1: Android Adapter 0100 Removable CD-ROM SCSI-2 device da1 at umass-sim1 bus 1 scbus5

Re: android bsd connectivity tools etc ?

2014-08-20 Thread Jamie Landeg-Jones
Julian H. Stacey j...@berklix.com wrote: Hi, Any tips for Android / FreeBSD BSD tools for connectivity etc ? I mainly use nfs / ssh (dropbear) / scp for connectivity over IPv6 to my local FreeBSD server. It works quite well - I even have automated cron rsync deduped backups! NFS is used for

Re: [RFC] Add support for hardware transmit rate limiting queues [WAS: Add support for changing the flow ID of TCP connections]

2014-08-20 Thread Luigi Rizzo
On Wed, Aug 20, 2014 at 9:34 AM, Hans Petter Selasky h...@selasky.org wrote: Hi, A month has passed since the last e-mail on this topic, and in the meanwhile some new patches have been created and tested: Basically the approach has been changed a little bit: - The creation of hardware

Re: [RFC] Add support for hardware transmit rate limiting queues [WAS: Add support for changing the flow ID of TCP connections]

2014-08-20 Thread Hans Petter Selasky
Hi Luigi, On 08/20/14 11:32, Luigi Rizzo wrote: On Wed, Aug 20, 2014 at 9:34 AM, Hans Petter Selasky h...@selasky.org wrote: Hi, A month has passed since the last e-mail on this topic, and in the meanwhile some new patches have been created and tested: Basically the approach has been

Re: [RFC] Add support for hardware transmit rate limiting queues [WAS: Add support for changing the flow ID of TCP connections]

2014-08-20 Thread Luigi Rizzo
On Wed, Aug 20, 2014 at 3:29 PM, Hans Petter Selasky h...@selasky.org wrote: Hi Luigi, On 08/20/14 11:32, Luigi Rizzo wrote: On Wed, Aug 20, 2014 at 9:34 AM, Hans Petter Selasky h...@selasky.org wrote: Hi, A month has passed since the last e-mail on this topic, and in the meanwhile

Re: [RFC] Add support for hardware transmit rate limiting queues [WAS: Add support for changing the flow ID of TCP connections]

2014-08-20 Thread K. Macy
On Wed, Aug 20, 2014 at 7:41 AM, Luigi Rizzo ri...@iet.unipi.it wrote: On Wed, Aug 20, 2014 at 3:29 PM, Hans Petter Selasky h...@selasky.org wrote: Hi Luigi, On 08/20/14 11:32, Luigi Rizzo wrote: On Wed, Aug 20, 2014 at 9:34 AM, Hans Petter Selasky h...@selasky.org wrote:

[CFT] SSP Package Repository available

2014-08-20 Thread Bryan Drewery
On 9/21/2013 5:49 AM, Bryan Drewery wrote: Ports now support enabling Stack Protector [1] support on FreeBSD 10 i386 and amd64, and older releases on amd64 only currently. Support may be added for earlier i386 releases once all ports properly respect LDFLAGS. To enable, just add

RFC: Remove pty(4)

2014-08-20 Thread Davide Italiano
One of my personal goals for 11 is to get rid of cloning mechanism entirely, and pty(4) is one of the few in-kernel drivers still relying on such mechanism. It's not possible, at least to my understanding, converting pty(4) to cdevpriv(9) as happened with other drivers. This is mainly because we

Re: RFC: Remove pty(4)

2014-08-20 Thread Alfred Perlstein
On 8/20/14 11:00 AM, Davide Italiano wrote: One of my personal goals for 11 is to get rid of cloning mechanism entirely, and pty(4) is one of the few in-kernel drivers still relying on such mechanism. It's not possible, at least to my understanding, converting pty(4) to cdevpriv(9) as happened

Re: RFC: Remove pty(4)

2014-08-20 Thread Hans Petter Selasky
On 08/20/14 20:00, Davide Italiano wrote: One of my personal goals for 11 is to get rid of cloning mechanism entirely, and pty(4) is one of the few in-kernel drivers still relying on such mechanism. It's not possible, at least to my understanding, converting pty(4) to cdevpriv(9) as happened

Re: RFC: Remove pty(4)

2014-08-20 Thread Julian Elischer
On 8/20/14, 11:00 AM, Davide Italiano wrote: One of my personal goals for 11 is to get rid of cloning mechanism entirely, and pty(4) is one of the few in-kernel drivers still relying on such mechanism. It's not possible, at least to my understanding, converting pty(4) to cdevpriv(9) as happened

Re: RFC: Remove pty(4)

2014-08-20 Thread Garrett Cooper
On Aug 20, 2014, at 11:05, Alfred Perlstein bri...@mu.org wrote: On 8/20/14 11:00 AM, Davide Italiano wrote: One of my personal goals for 11 is to get rid of cloning mechanism entirely, and pty(4) is one of the few in-kernel drivers still relying on such mechanism. It's not possible, at

Re: RFC: Remove pty(4)

2014-08-20 Thread Bryan Drewery
On 8/20/2014 1:13 PM, Julian Elischer wrote: On 8/20/14, 11:00 AM, Davide Italiano wrote: One of my personal goals for 11 is to get rid of cloning mechanism entirely, and pty(4) is one of the few in-kernel drivers still relying on such mechanism. It's not possible, at least to my

Re: [RFC] Add support for hardware transmit rate limiting queues [WAS: Add support for changing the flow ID of TCP connections]

2014-08-20 Thread Navdeep Parhar
On 08/20/14 00:34, Hans Petter Selasky wrote: Hi, A month has passed since the last e-mail on this topic, and in the meanwhile some new patches have been created and tested: Basically the approach has been changed a little bit: - The creation of hardware transmit rings has been made

Re: [RFC] Add support for hardware transmit rate limiting queues [WAS: Add support for changing the flow ID of TCP connections]

2014-08-20 Thread Hans Petter Selasky
On 08/20/14 20:44, Navdeep Parhar wrote: On 08/20/14 00:34, Hans Petter Selasky wrote: Hi, A month has passed since the last e-mail on this topic, and in the meanwhile some new patches have been created and tested: Basically the approach has been changed a little bit: - The creation of

Re: RFC: Remove pty(4)

2014-08-20 Thread Slawa Olhovchenkov
On Wed, Aug 20, 2014 at 11:00:14AM -0700, Davide Italiano wrote: One of my personal goals for 11 is to get rid of cloning mechanism entirely, and pty(4) is one of the few in-kernel drivers still relying on such mechanism. It's not possible, at least to my understanding, converting pty(4) to

Re: [RFC] Add support for hardware transmit rate limiting queues [WAS: Add support for changing the flow ID of TCP connections]

2014-08-20 Thread Navdeep Parhar
On 08/20/14 12:25, Hans Petter Selasky wrote: On 08/20/14 20:44, Navdeep Parhar wrote: On 08/20/14 00:34, Hans Petter Selasky wrote: Hi, A month has passed since the last e-mail on this topic, and in the meanwhile some new patches have been created and tested: Basically the approach has been

Re: [RFC] Add support for hardware transmit rate limiting queues [WAS: Add support for changing the flow ID of TCP connections]

2014-08-20 Thread K. Macy
- uint32_t - m_flowid_t is plain gratuitous. Now we need to include mbuf.h in more places just to get this definition. What's the advantage of this? style(9) isn't too fond of typedefs either. Also, drivers *do* need to know the width of the flowid. At least lagg(4) looks

gbde destroy doesn't match man page?

2014-08-20 Thread Michael W. Lucas
Hi, Playing with GBDE for my FreeBSD disk book, on: # uname -a FreeBSD storm 11.0-CURRENT FreeBSD 11.0-CURRENT #6 r269010: Wed Jul 23 11:13:17 EDT 2014 mwlucas@storm:/usr/obj/usr/src/sys/GENERIC amd64 According to the man page, I should be able to destroy all copies of the key with gbde

Re: RFC: Remove pty(4)

2014-08-20 Thread Sam Fourman Jr.
Sam Fourman Jr. On Aug 20, 2014 1:00 PM, Davide Italiano dav...@freebsd.org wrote: One of my personal goals for 11 is to get rid of cloning mechanism entirely, and pty(4) is one of the few in-kernel drivers still relying on such mechanism. It's not possible, at least to my understanding,