[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 app

Re: android bsd connectivity tools etc ?

2014-08-20 Thread Jamie Landeg-Jones
Shane Ambler 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 target 0 lun 2 >

Re: android bsd connectivity tools etc ?

2014-08-20 Thread Jamie Landeg-Jones
"Julian H. Stacey" 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 mounting my me

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 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 rin

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 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:

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 wrote: > Hi Luigi, > > > On 08/20/14 11:32, Luigi Rizzo wrote: > >> On Wed, Aug 20, 2014 at 9:34 AM, Hans Petter Selasky >> wrote: >> >> Hi, >>> >>> A month has passed since the last e-mail on this topic, and in the >>> meanwhile some new pat

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 wrote: > On Wed, Aug 20, 2014 at 3:29 PM, Hans Petter Selasky > wrote: > > > Hi Luigi, > > > > > > On 08/20/14 11:32, Luigi Rizzo wrote: > > > >> On Wed, Aug 20, 2014 at 9:34 AM, Hans Petter Selasky > >> wrote: > >> > >> Hi, > >>> > >>> A month has

[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 WIT

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 al

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 w

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 with

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 w

Re: RFC: Remove pty(4)

2014-08-20 Thread Garrett Cooper
> On Aug 20, 2014, at 11:05, Alfred Perlstein 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 lea

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 unde

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 independen

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 hardwa

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) t

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)

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 de

Re: RFC: Remove pty(4)

2014-08-20 Thread Sam Fourman Jr.
Sam Fourman Jr. On Aug 20, 2014 1:00 PM, "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