Re: igb and ALTQ in 9.1-rc3

[Barney Cordoba]

--- On Tue, 4/2/13, Adrian Chadd  wrote:

> From: Adrian Chadd 
> Subject: Re: igb and ALTQ in 9.1-rc3
> To: "Nick Rogers" 
> Cc: "Karim Fodil-Lemelin" , 
> "freebsd-net@freebsd.org" 
> Date: Tuesday, April 2, 2013, 6:39 PM
> Yes:
> 
> * you need to add it to conf/options - see if there's an
> opt_igb.h to
> add it to, otherwise you'll need to add one;
> * Make sure the driver code includes opt_igb.h;
> * Then make sure you make kernel modules using either make
> buildkernel
> KERNCONF=X, or you set the environment appropriately so the
> build
> scripts can find your kernel build directory (where it
> populates all
> the opt_xxx.h includes) and it'll have this module set.
> 
> Hopefully Jack will do this.
> 
> Yes, we need a better queue management discipline API in the
> kernel.
> Jacks' just falling afoul of the fact we don't have one.
> It's not his
> fault.

That's not true at all. For a bridged system running a firewall or doing
filtering, virtually all of the proper design can be done in 
the ethernet driver. Or course if you have 2 different drivers then you
need a different scheme, but if the input and the output is the same driver
you can manage virtually all of the contention. You can't just randomly
do things; you have to design to minimize lock contention. Drivers that
seem to work fine at low volume blow up quickly as contention increases.

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

Re: igb and ALTQ in 9.1-rc3

[Barney Cordoba]

Firstly, my OP was not intended to have anything to do with Jack. 
Frankly, he's just a mechanical programmer and not a designer, so its 
others that should be responsible for guiding him. There *should* be
someone at FreeBSD who is responsible for taking mechanically sound drivers
and optimizing them. But in the open source world, that function doesn't
usually exist. 

But the idea that the FreeBSD community refuses to point out that some
things just don't work well hurts people in the community. The portrayal
of every feature in FreeBSD as being equally useful and well done doesn't
provide the information that users need to make decisions about what to
use to run their businesses. 

It also hurts people that you've made IGB worse in FreeBSD 9. There's 
*some* expectation that it should be better in 9 than 7 or 8, and that it
should have fewer bugs. But in an effort to force in a rickety
implementation of multi-queue, you've converted the driver into something
that is guaranteed to rob any system of cpu cycles.

I wrote a multiqueue driver for 7 for igb that works very well, and I'd
hoped to be able to use igb in 9 without having to port it, even if it 
wasn't as good. But it's not just not as good; it's unusable in a heavy
production environment.

While it's noble (and convenient) for you folks who have jobs where you
get paid to write open source code to rip others for "not contributing", 
Im sure that some of you with real jobs know that when someone pays you a 
lot of money to write code, you're not free to share the code or even the 
specific techniques publicly. After all, technique is the difference between a 
good and a bad driver.

I try to drop hints, but Jack's lack of curiosity as to how to make the
driver better is particularly troubling. So I just have to recommend that
igb cards not be used for production flows, because there is little hope
that it will improve any time soon.


BC

--- On Sun, 3/31/13, Adrian Chadd  wrote:

> From: Adrian Chadd 
> Subject: Re: igb and ALTQ in 9.1-rc3
> To: "Barney Cordoba" 
> Cc: "Jeffrey EPieper" , "Nick Rogers" 
> , "Clement Hermann (nodens)" , 
> "Jack Vogel" , "freebsd-net@freebsd.org" 
> 
> Date: Sunday, March 31, 2013, 2:48 PM
> Barney,
> 
> As much as we'd like it, Jack's full time job involves other
> things
> besides supporting FreeBSD.
> 
> If you want to see it done better, please work with the
> FreeBSD
> developer community and improve the intel driver. No-one is
> stopping
> you from stepping in.
> 
> In fact, this would be _beneficial_ to Jack's work inside
> Intel with
> FreeBSD. If there is more of an active community
> participating with
> the intel drivers and more companies choosing intel hardware
> for
> FreeBSD network services, Intel will likely dump more effort
> into
> FreeBSD.
> 
> So please, stop your non-constructive trolling and
> complaining and put
> your skills to use for the greater good.
> 
> Sheesh. Intel have supplied a very thorough, detailed driver
> as well
> as programming and errata datasheets for their chips. We
> aren't in the
> dark here. There's more than enough rope to hang ourselves
> with.
> Please focus on making it better.
> 
> 
> Adrian
> 
> 
> On 31 March 2013 05:35, Barney Cordoba 
> wrote:
> > The reason that Jack is a no better programmer now than
> he was in 2009 might have something to do with the fact that
> he hides when his work is criticized.
> > Why not release the benchmarks you did while designing
> the igb driver, Jack? Say what,you didn't do any
> benchmarking? How does the default driver perform, say in a
> firewall,with 1000 user load? What's the optimum number of
> queues to use in such a system?What's the effect of CPU
> binding? What's the effect with multiple cards when you
> havemore queues than you have physical cpus?
> > What made you decide to use buf_ring? Something new to
> play with?
> > I'm guessing that you have no idea.
> > BC--- On Fri, 3/29/13, Jack Vogel 
> wrote:
> >
> > From: Jack Vogel 
> > Subject: Re: igb and ALTQ in 9.1-rc3
> > To: "Pieper, Jeffrey E" 
> > Cc: "Barney Cordoba" ,
> "Nick Rogers" ,
> "freebsd-net@freebsd.org"
> ,
> "Clement Hermann (nodens)" 
> > Date: Friday, March 29, 2013, 12:36 PM
> >
> > Fortunately, Barney doesn't speak for me, or for Intel,
> and I've long ago realized its pointless to
> > attempt anything like a fair conversation with him. The
> only thing he's ever contributed is slander
> >
> > and pseudo-crit

Re: igb and ALTQ in 9.1-rc3

[Nick Rogers]

On Tue, Apr 2, 2013 at 3:39 PM, Adrian Chadd  wrote:
> Yes:
>
> * you need to add it to conf/options - see if there's an opt_igb.h to
> add it to, otherwise you'll need to add one;
> * Make sure the driver code includes opt_igb.h;
> * Then make sure you make kernel modules using either make buildkernel
> KERNCONF=X, or you set the environment appropriately so the build
> scripts can find your kernel build directory (where it populates all
> the opt_xxx.h includes) and it'll have this module set.

Thanks, I figured as much.

>
> Hopefully Jack will do this.

This should probably be done for EM_MULTIQUEUE and IGB_LEGACY_TX options.

>
> Yes, we need a better queue management discipline API in the kernel.
> Jacks' just falling afoul of the fact we don't have one. It's not his
> fault.

No blame from me... He's been very helpful so far as always.

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

Re: igb and ALTQ in 9.1-rc3

[Adrian Chadd]

Yes:

* you need to add it to conf/options - see if there's an opt_igb.h to
add it to, otherwise you'll need to add one;
* Make sure the driver code includes opt_igb.h;
* Then make sure you make kernel modules using either make buildkernel
KERNCONF=X, or you set the environment appropriately so the build
scripts can find your kernel build directory (where it populates all
the opt_xxx.h includes) and it'll have this module set.

Hopefully Jack will do this.

Yes, we need a better queue management discipline API in the kernel.
Jacks' just falling afoul of the fact we don't have one. It's not his
fault.



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

Re: igb and ALTQ in 9.1-rc3

[Nick Rogers]

On Tue, Apr 2, 2013 at 1:59 PM, Karim Fodil-Lemelin
 wrote:
> Hi Nick,
>
> Thanks for the testing, I am glad I could help. Please note that by setting:
>
>
> static int igb_num_queues = 1;
>
> You are effectively only using 1 TX queue from the hardware (instead of 4 or
> 8) so this might not be applicable to a generic kernel without ALTQ.

Yes I am aware of this, thanks.

Also, FWIW, the changes Jack made to e1000 in HEAD are working for me
now and they should get MFCd eventually. If you set IGB_LEGACY_TX, the
multiqueue stack is skipped in favor of the old stuff which enables
ALTQ to work correctly again. This seems like it may be a cleaner
approach than the patch you suggested.

I am unsure the best way to set IGB_LEGACY_TX without adding a #define
IGB_LEGACY_TX to if_igb.c. Adding this to CFLAGS in make.conf and/or
the kernel conf does not seem to take effect when building the driver
into the kernel (i.e., not as a module). Can anyone comment on a
correct way to set this macro without modifying the driver code?

>
> Best regards,
>
> Karim.
>
>
> On 02/04/2013 1:17 PM, Nick Rogers wrote:
>>
>> On Tue, Apr 2, 2013 at 9:17 AM, Nick Rogers  wrote:
>>>
>>> On Tue, Apr 2, 2013 at 7:47 AM, Karim Fodil-Lemelin
>>>  wrote:

 Hi Nick,

 Unfortunately I do not have a FBSD 9 box around where I can compile and
 test
 this so bear with me as this is pretty much straight out of looking at
 the
 source code directly (i.e it might not even compile).

 But if your desperate please try the following (untested) patch (applied
 to
 stable/9):
>>>
>>> Thanks for the attempt. The patch does not apply cleanly to stable/9
>>> for me. Also I am trying to work with the latest commits Jack has made
>>> to HEAD that allow defining IGB_LEGACY_TX to disable the new
>>> multiqueue stack. It seems the gist of this is the same as what you
>>> have changed, unless I am missing something.
>>>
>> OK, although your patch did not compile even after applying it
>> manually, It made me understand the gist of what you were saying about
>> "keeping igb_start() defined and using igb_mq_start_locked() inside it
>> instead of igb_start_locked()". I was able to make my own patch that
>> is very similar to your intention (and your patch) and it compiled,
>> and solved my problem. ALTQ now works with igb (I am able to load my
>> pf.conf, use PF, etc). Thanks a lot for the help. I will try and work
>> with Jack to perhaps integrate this in a more official manner, as this
>> is indeed a bit different than what he has changed in HEAD w.r.t
>> IGB_LEGACY_TX configurability.
>>
>> Below is the diff of my changes against stable/9.
>>
>> Index: sys/dev/e1000/if_igb.c
>> ===
>> --- sys/dev/e1000/if_igb.c (revision 249024)
>> +++ sys/dev/e1000/if_igb.c (working copy)
>> @@ -179,13 +179,13 @@
>>   static int igb_shutdown(device_t);
>>   static int igb_suspend(device_t);
>>   static int igb_resume(device_t);
>> +static void igb_start(struct ifnet *);
>>   #if __FreeBSD_version >= 80
>>   static int igb_mq_start(struct ifnet *, struct mbuf *);
>>   static int igb_mq_start_locked(struct ifnet *, struct tx_ring *);
>>   static void igb_qflush(struct ifnet *);
>>   static void igb_deferred_mq_start(void *, int);
>>   #else
>> -static void igb_start(struct ifnet *);
>>   static void igb_start_locked(struct tx_ring *, struct ifnet *ifp);
>>   #endif
>>   static int igb_ioctl(struct ifnet *, u_long, caddr_t);
>> @@ -377,7 +377,7 @@
>>   ** This will autoconfigure based on
>>   ** the number of CPUs if left at 0.
>>   */
>> -static int igb_num_queues = 0;
>> +static int igb_num_queues = 1;
>>   TUNABLE_INT("hw.igb.num_queues", &igb_num_queues);
>>   SYSCTL_INT(_hw_igb, OID_AUTO, num_queues, CTLFLAG_RDTUN,
>> &igb_num_queues, 0,
>>   "Number of queues to configure, 0 indicates autoconfigure");
>> @@ -926,6 +926,8 @@
>>txr->queue_status |= IGB_QUEUE_WORKING;
>>}
>>   }
>> +
>> +#else /* __FreeBSD_version >= 80 */
>>
>>   /*
>>* Legacy TX driver routine, called from the
>> @@ -940,13 +942,16 @@
>>
>>if (ifp->if_drv_flags & IFF_DRV_RUNNING) {
>>IGB_TX_LOCK(txr);
>> - igb_start_locked(txr, ifp);
>> + #if __FreeBSD_version < 80
>> +   igb_start_locked(txr, ifp);
>> + #else
>> +   igb_mq_start_locked(ifp, txr);
>> + #endif
>>IGB_TX_UNLOCK(txr);
>>}
>>return;
>>   }
>>
>> -#else /* __FreeBSD_version >= 80 */
>>
>>   /*
>>   ** Multiqueue Transmit Entry:
>> @@ -3089,12 +3094,11 @@
>>   #if __FreeBSD_version >= 80
>>ifp->if_transmit = igb_mq_start;
>>ifp->if_qflush = igb_qflush;
>> -#else
>> +#endif
>>ifp->if_start = igb_start;
>>IFQ_SET_MAXLEN(&ifp->if_snd, adapter->num_tx_desc - 1);
>>ifp->if_snd.ifq_drv_maxlen = adapter->num_tx_desc - 1;
>>IFQ_SET_READY(&ifp->if_snd);
>> -#endif
>>
>>ether_ifattach(ifp, adapter->hw.mac.addr);
>>
>>
>>
 diff --git a/sys/dev

Re: igb and ALTQ in 9.1-rc3

[Karim Fodil-Lemelin]

Hi Nick,

Thanks for the testing, I am glad I could help. Please note that by setting:

static int igb_num_queues = 1;

You are effectively only using 1 TX queue from the hardware (instead of 
4 or 8) so this might not be applicable to a generic kernel without ALTQ.


Best regards,

Karim.

On 02/04/2013 1:17 PM, Nick Rogers wrote:

On Tue, Apr 2, 2013 at 9:17 AM, Nick Rogers  wrote:

On Tue, Apr 2, 2013 at 7:47 AM, Karim Fodil-Lemelin
 wrote:

Hi Nick,

Unfortunately I do not have a FBSD 9 box around where I can compile and test
this so bear with me as this is pretty much straight out of looking at the
source code directly (i.e it might not even compile).

But if your desperate please try the following (untested) patch (applied to
stable/9):

Thanks for the attempt. The patch does not apply cleanly to stable/9
for me. Also I am trying to work with the latest commits Jack has made
to HEAD that allow defining IGB_LEGACY_TX to disable the new
multiqueue stack. It seems the gist of this is the same as what you
have changed, unless I am missing something.


OK, although your patch did not compile even after applying it
manually, It made me understand the gist of what you were saying about
"keeping igb_start() defined and using igb_mq_start_locked() inside it
instead of igb_start_locked()". I was able to make my own patch that
is very similar to your intention (and your patch) and it compiled,
and solved my problem. ALTQ now works with igb (I am able to load my
pf.conf, use PF, etc). Thanks a lot for the help. I will try and work
with Jack to perhaps integrate this in a more official manner, as this
is indeed a bit different than what he has changed in HEAD w.r.t
IGB_LEGACY_TX configurability.

Below is the diff of my changes against stable/9.

Index: sys/dev/e1000/if_igb.c
===
--- sys/dev/e1000/if_igb.c (revision 249024)
+++ sys/dev/e1000/if_igb.c (working copy)
@@ -179,13 +179,13 @@
  static int igb_shutdown(device_t);
  static int igb_suspend(device_t);
  static int igb_resume(device_t);
+static void igb_start(struct ifnet *);
  #if __FreeBSD_version >= 80
  static int igb_mq_start(struct ifnet *, struct mbuf *);
  static int igb_mq_start_locked(struct ifnet *, struct tx_ring *);
  static void igb_qflush(struct ifnet *);
  static void igb_deferred_mq_start(void *, int);
  #else
-static void igb_start(struct ifnet *);
  static void igb_start_locked(struct tx_ring *, struct ifnet *ifp);
  #endif
  static int igb_ioctl(struct ifnet *, u_long, caddr_t);
@@ -377,7 +377,7 @@
  ** This will autoconfigure based on
  ** the number of CPUs if left at 0.
  */
-static int igb_num_queues = 0;
+static int igb_num_queues = 1;
  TUNABLE_INT("hw.igb.num_queues", &igb_num_queues);
  SYSCTL_INT(_hw_igb, OID_AUTO, num_queues, CTLFLAG_RDTUN, &igb_num_queues, 0,
  "Number of queues to configure, 0 indicates autoconfigure");
@@ -926,6 +926,8 @@
   txr->queue_status |= IGB_QUEUE_WORKING;
   }
  }
+
+#else /* __FreeBSD_version >= 80 */

  /*
   * Legacy TX driver routine, called from the
@@ -940,13 +942,16 @@

   if (ifp->if_drv_flags & IFF_DRV_RUNNING) {
   IGB_TX_LOCK(txr);
- igb_start_locked(txr, ifp);
+ #if __FreeBSD_version < 80
+   igb_start_locked(txr, ifp);
+ #else
+   igb_mq_start_locked(ifp, txr);
+ #endif
   IGB_TX_UNLOCK(txr);
   }
   return;
  }

-#else /* __FreeBSD_version >= 80 */

  /*
  ** Multiqueue Transmit Entry:
@@ -3089,12 +3094,11 @@
  #if __FreeBSD_version >= 80
   ifp->if_transmit = igb_mq_start;
   ifp->if_qflush = igb_qflush;
-#else
+#endif
   ifp->if_start = igb_start;
   IFQ_SET_MAXLEN(&ifp->if_snd, adapter->num_tx_desc - 1);
   ifp->if_snd.ifq_drv_maxlen = adapter->num_tx_desc - 1;
   IFQ_SET_READY(&ifp->if_snd);
-#endif

   ether_ifattach(ifp, adapter->hw.mac.addr);




diff --git a/sys/dev/e1000/if_igb.c b/sys/dev/e1000/if_igb.c
index 30bb052..3a6de2e 100644
--- a/sys/dev/e1000/if_igb.c
+++ b/sys/dev/e1000/if_igb.c
@@ -179,13 +179,13 @@ static int igb_detach(device_t);
  static int igb_shutdown(device_t);
  static int igb_suspend(device_t);
  static int igb_resume(device_t);
+static voidigb_start(struct ifnet *);
  #if __FreeBSD_version >= 80
  static int igb_mq_start(struct ifnet *, struct mbuf *);
  static int igb_mq_start_locked(struct ifnet *, struct tx_ring *);
  static voidigb_qflush(struct ifnet *);
  static voidigb_deferred_mq_start(void *, int);
  #else
-static voidigb_start(struct ifnet *);
  static voidigb_start_locked(struct tx_ring *, struct ifnet *ifp);
  #endif
  static int igb_ioctl(struct ifnet *, u_long, caddr_t);
@@ -377,7 +377,7 @@ SYSCTL_INT(_hw_igb, OID_AUTO, header_split,
CTLFLAG_RDTUN, &igb_header_split, 0,
  ** This will autoconfigure based on
  ** the number of CPUs if left at 0.
  */
-static int igb_num_queues = 0;
+static int igb_num_queues = 1;
  TUNABLE_INT("hw.igb.num_queues", &igb_num_queues);
  SYSCTL_INT(_hw_i

Re: igb and ALTQ in 9.1-rc3

[Nick Rogers]

On Tue, Apr 2, 2013 at 9:17 AM, Nick Rogers  wrote:
> On Tue, Apr 2, 2013 at 7:47 AM, Karim Fodil-Lemelin
>  wrote:
>> Hi Nick,
>>
>> Unfortunately I do not have a FBSD 9 box around where I can compile and test
>> this so bear with me as this is pretty much straight out of looking at the
>> source code directly (i.e it might not even compile).
>>
>> But if your desperate please try the following (untested) patch (applied to
>> stable/9):
>
> Thanks for the attempt. The patch does not apply cleanly to stable/9
> for me. Also I am trying to work with the latest commits Jack has made
> to HEAD that allow defining IGB_LEGACY_TX to disable the new
> multiqueue stack. It seems the gist of this is the same as what you
> have changed, unless I am missing something.
>

OK, although your patch did not compile even after applying it
manually, It made me understand the gist of what you were saying about
"keeping igb_start() defined and using igb_mq_start_locked() inside it
instead of igb_start_locked()". I was able to make my own patch that
is very similar to your intention (and your patch) and it compiled,
and solved my problem. ALTQ now works with igb (I am able to load my
pf.conf, use PF, etc). Thanks a lot for the help. I will try and work
with Jack to perhaps integrate this in a more official manner, as this
is indeed a bit different than what he has changed in HEAD w.r.t
IGB_LEGACY_TX configurability.

Below is the diff of my changes against stable/9.

Index: sys/dev/e1000/if_igb.c
===
--- sys/dev/e1000/if_igb.c (revision 249024)
+++ sys/dev/e1000/if_igb.c (working copy)
@@ -179,13 +179,13 @@
 static int igb_shutdown(device_t);
 static int igb_suspend(device_t);
 static int igb_resume(device_t);
+static void igb_start(struct ifnet *);
 #if __FreeBSD_version >= 80
 static int igb_mq_start(struct ifnet *, struct mbuf *);
 static int igb_mq_start_locked(struct ifnet *, struct tx_ring *);
 static void igb_qflush(struct ifnet *);
 static void igb_deferred_mq_start(void *, int);
 #else
-static void igb_start(struct ifnet *);
 static void igb_start_locked(struct tx_ring *, struct ifnet *ifp);
 #endif
 static int igb_ioctl(struct ifnet *, u_long, caddr_t);
@@ -377,7 +377,7 @@
 ** This will autoconfigure based on
 ** the number of CPUs if left at 0.
 */
-static int igb_num_queues = 0;
+static int igb_num_queues = 1;
 TUNABLE_INT("hw.igb.num_queues", &igb_num_queues);
 SYSCTL_INT(_hw_igb, OID_AUTO, num_queues, CTLFLAG_RDTUN, &igb_num_queues, 0,
 "Number of queues to configure, 0 indicates autoconfigure");
@@ -926,6 +926,8 @@
  txr->queue_status |= IGB_QUEUE_WORKING;
  }
 }
+
+#else /* __FreeBSD_version >= 80 */

 /*
  * Legacy TX driver routine, called from the
@@ -940,13 +942,16 @@

  if (ifp->if_drv_flags & IFF_DRV_RUNNING) {
  IGB_TX_LOCK(txr);
- igb_start_locked(txr, ifp);
+ #if __FreeBSD_version < 80
+   igb_start_locked(txr, ifp);
+ #else
+   igb_mq_start_locked(ifp, txr);
+ #endif
  IGB_TX_UNLOCK(txr);
  }
  return;
 }

-#else /* __FreeBSD_version >= 80 */

 /*
 ** Multiqueue Transmit Entry:
@@ -3089,12 +3094,11 @@
 #if __FreeBSD_version >= 80
  ifp->if_transmit = igb_mq_start;
  ifp->if_qflush = igb_qflush;
-#else
+#endif
  ifp->if_start = igb_start;
  IFQ_SET_MAXLEN(&ifp->if_snd, adapter->num_tx_desc - 1);
  ifp->if_snd.ifq_drv_maxlen = adapter->num_tx_desc - 1;
  IFQ_SET_READY(&ifp->if_snd);
-#endif

  ether_ifattach(ifp, adapter->hw.mac.addr);



>>
>> diff --git a/sys/dev/e1000/if_igb.c b/sys/dev/e1000/if_igb.c
>> index 30bb052..3a6de2e 100644
>> --- a/sys/dev/e1000/if_igb.c
>> +++ b/sys/dev/e1000/if_igb.c
>> @@ -179,13 +179,13 @@ static int igb_detach(device_t);
>>  static int igb_shutdown(device_t);
>>  static int igb_suspend(device_t);
>>  static int igb_resume(device_t);
>> +static voidigb_start(struct ifnet *);
>>  #if __FreeBSD_version >= 80
>>  static int igb_mq_start(struct ifnet *, struct mbuf *);
>>  static int igb_mq_start_locked(struct ifnet *, struct tx_ring *);
>>  static voidigb_qflush(struct ifnet *);
>>  static voidigb_deferred_mq_start(void *, int);
>>  #else
>> -static voidigb_start(struct ifnet *);
>>  static voidigb_start_locked(struct tx_ring *, struct ifnet *ifp);
>>  #endif
>>  static int igb_ioctl(struct ifnet *, u_long, caddr_t);
>> @@ -377,7 +377,7 @@ SYSCTL_INT(_hw_igb, OID_AUTO, header_split,
>> CTLFLAG_RDTUN, &igb_header_split, 0,
>>  ** This will autoconfigure based on
>>  ** the number of CPUs if left at 0.
>>  */
>> -static int igb_num_queues = 0;
>> +static int igb_num_queues = 1;
>>  TUNABLE_INT("hw.igb.num_queues", &igb_num_queues);
>>  SYSCTL_INT(_hw_igb, OID_AUTO, num_queues, CTLFLAG_RDTUN, &igb_num_queues,
>> 0,
>>  "Number of queues to configure, 0 indicates autoconfigure");
>> @@ -926,6 +926,8 @@ igb_start_locked(struct tx_ring *txr, struct ifnet *ifp)
>> txr->queue_status |= IGB_QUEUE_WORKING

Re: igb and ALTQ in 9.1-rc3

[Nick Rogers]

On Tue, Apr 2, 2013 at 7:47 AM, Karim Fodil-Lemelin
 wrote:
> Hi Nick,
>
> Unfortunately I do not have a FBSD 9 box around where I can compile and test
> this so bear with me as this is pretty much straight out of looking at the
> source code directly (i.e it might not even compile).
>
> But if your desperate please try the following (untested) patch (applied to
> stable/9):

Thanks for the attempt. The patch does not apply cleanly to stable/9
for me. Also I am trying to work with the latest commits Jack has made
to HEAD that allow defining IGB_LEGACY_TX to disable the new
multiqueue stack. It seems the gist of this is the same as what you
have changed, unless I am missing something.

>
> diff --git a/sys/dev/e1000/if_igb.c b/sys/dev/e1000/if_igb.c
> index 30bb052..3a6de2e 100644
> --- a/sys/dev/e1000/if_igb.c
> +++ b/sys/dev/e1000/if_igb.c
> @@ -179,13 +179,13 @@ static int igb_detach(device_t);
>  static int igb_shutdown(device_t);
>  static int igb_suspend(device_t);
>  static int igb_resume(device_t);
> +static voidigb_start(struct ifnet *);
>  #if __FreeBSD_version >= 80
>  static int igb_mq_start(struct ifnet *, struct mbuf *);
>  static int igb_mq_start_locked(struct ifnet *, struct tx_ring *);
>  static voidigb_qflush(struct ifnet *);
>  static voidigb_deferred_mq_start(void *, int);
>  #else
> -static voidigb_start(struct ifnet *);
>  static voidigb_start_locked(struct tx_ring *, struct ifnet *ifp);
>  #endif
>  static int igb_ioctl(struct ifnet *, u_long, caddr_t);
> @@ -377,7 +377,7 @@ SYSCTL_INT(_hw_igb, OID_AUTO, header_split,
> CTLFLAG_RDTUN, &igb_header_split, 0,
>  ** This will autoconfigure based on
>  ** the number of CPUs if left at 0.
>  */
> -static int igb_num_queues = 0;
> +static int igb_num_queues = 1;
>  TUNABLE_INT("hw.igb.num_queues", &igb_num_queues);
>  SYSCTL_INT(_hw_igb, OID_AUTO, num_queues, CTLFLAG_RDTUN, &igb_num_queues,
> 0,
>  "Number of queues to configure, 0 indicates autoconfigure");
> @@ -926,6 +926,8 @@ igb_start_locked(struct tx_ring *txr, struct ifnet *ifp)
> txr->queue_status |= IGB_QUEUE_WORKING;
> }
>  }
> +
> +#endif /* __FreeBSD_version < 80 */
>
>  /*
>   * Legacy TX driver routine, called from the
> @@ -940,14 +942,17 @@ igb_start(struct ifnet *ifp)
>
> if (ifp->if_drv_flags & IFF_DRV_RUNNING) {
> IGB_TX_LOCK(txr);
> +#if __FreeBSD_version < 80
> +   igb_start_locked(txr, ifp);
> +#else
> +   igb_mq_start_locked(ifp, txr, NULL);
> +#endif
> igb_start_locked(txr, ifp);
> IGB_TX_UNLOCK(txr);
> }
> return;
>  }
>
> -#else /* __FreeBSD_version >= 80 */
> -
>  /*
>  ** Multiqueue Transmit Entry:
>  **  quick turnaround to the stack
> @@ -3089,12 +3094,11 @@ igb_setup_interface(device_t dev, struct adapter
> *adapter)
>  #if __FreeBSD_version >= 80
> ifp->if_transmit = igb_mq_start;
> ifp->if_qflush = igb_qflush;
> -#else
> +#endif
>
> ifp->if_start = igb_start;
> IFQ_SET_MAXLEN(&ifp->if_snd, adapter->num_tx_desc - 1);
> ifp->if_snd.ifq_drv_maxlen = adapter->num_tx_desc - 1;
> IFQ_SET_READY(&ifp->if_snd);
> -#endif
>
> ether_ifattach(ifp, adapter->hw.mac.addr);
>
>
>
>
> On 02/04/2013 9:58 AM, Nick Rogers wrote:
>>
>> On Tuesday, April 2, 2013, Karim Fodil-Lemelin wrote:
>>
>>> Hi Nick,
>>>
>>> Can you verify that you have at least one of those options in your kernel
>>> config file:
>>>
>>> ALTQ_CBQ
>>> ALTQ_PRIQ
>>> ALTQ_HFSC
>>
>>
>> Yes I have hfsc included in the kernel. I have other machines using altq
>> with em(4) interfaces and similar pf configurations on the same kernel
>> that
>> work fine.
>>
>>
>>> Regards,
>>>
>>> Karim.
>>>
>>> On 01/04/2013 8:22 PM, Nick Rogers wrote:
>>>
>>> On Mon, Apr 1, 2013 at 8:44 AM, Karim Fodil-Lemelin
>>>  wrote:
>>>
>>> Hi Jack,
>>>
>>> I think this would help M. Rogers case as we have done something similar
>>> here to circumvent the issue and it seems to work well. I would also add
>>> that when using ALTQ we found it much more stable to set the number of
>>> queues to 1:
>>>
>>> static int igb_num_queues = 1;
>>>
>>> Our approach consisted in keeping igb_start() defined and using
>>> igb_mq_start_locked() inside it instead of igb_start_locked().
>>>
>>> Regards,
>>>
>>> Karim.
>>>
>>> Thanks for the pointer.
>>>
>>> I've been working with Jack to get a fix for this in that downgrades
>>> the stack to the older if_start/non-multiqueue interface. See the
>>> following two commits he made to HEAD.
>>>
>>> http://svnweb.freebsd.org/**base/head/sys/dev/e1000/if_**
>>>
>>> igb.c?revision=248906&view=**markup
>>> http://svnweb.freebsd.org/**base/head/sys/dev/e1000/if_**
>>>
>>> igb.h?revision=248908&view=**markup

Re: igb and ALTQ in 9.1-rc3

[Nick Rogers]

On Tue, Apr 2, 2013 at 7:20 AM, Karim Fodil-Lemelin
 wrote:
> Hi Nick,
>
> You need to set the ALTQF_READY flag inside the igb driver. Make sure you
> have something like this in if_igb.c:
>
> ifp->if_start = igb_start;
> IFQ_SET_MAXLEN(&ifp->if_snd, adapter->num_tx_desc - 1);
> ifp->if_snd.ifq_drv_maxlen = adapter->num_tx_desc - 1;
> IFQ_SET_READY(&ifp->if_snd);
>
> The call to IFQ_SET_READY() is what will enable ALTQ on your device.

OK, thanks. As far as I can tell the call to IFQ_SET_READY is happening.

If you look at this commit Jack made:
http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_igb.c?r1=248906&r2=248905&pathrev=248906

If IGB_LEGACY_TX is defined, then IFQ_SET_READY is called. In
modules/igb/Makefile I have:

+# IGB_LEGACY_TX will override the stack if_transmit path and
+# instead use the older if_start non-multiqueue capable interface.
+# This might be desireable for testing, or to enable the use of
+# ALTQ.
+CFLAGS  += -DIGB_LEGACY_TX


>
> Regards,
>
> Karim.
>
>
> On 02/04/2013 9:58 AM, Nick Rogers wrote:
>>
>> On Tuesday, April 2, 2013, Karim Fodil-Lemelin wrote:
>>
>>> Hi Nick,
>>>
>>> Can you verify that you have at least one of those options in your kernel
>>> config file:
>>>
>>> ALTQ_CBQ
>>> ALTQ_PRIQ
>>> ALTQ_HFSC
>>
>>
>> Yes I have hfsc included in the kernel. I have other machines using altq
>> with em(4) interfaces and similar pf configurations on the same kernel
>> that
>> work fine.
>>
>>
>>> Regards,
>>>
>>> Karim.
>>>
>>> On 01/04/2013 8:22 PM, Nick Rogers wrote:
>>>
>>> On Mon, Apr 1, 2013 at 8:44 AM, Karim Fodil-Lemelin
>>>  wrote:
>>>
>>> Hi Jack,
>>>
>>> I think this would help M. Rogers case as we have done something similar
>>> here to circumvent the issue and it seems to work well. I would also add
>>> that when using ALTQ we found it much more stable to set the number of
>>> queues to 1:
>>>
>>> static int igb_num_queues = 1;
>>>
>>> Our approach consisted in keeping igb_start() defined and using
>>> igb_mq_start_locked() inside it instead of igb_start_locked().
>>>
>>> Regards,
>>>
>>> Karim.
>>>
>>> Thanks for the pointer.
>>>
>>> I've been working with Jack to get a fix for this in that downgrades
>>> the stack to the older if_start/non-multiqueue interface. See the
>>> following two commits he made to HEAD.
>>>
>>> http://svnweb.freebsd.org/**base/head/sys/dev/e1000/if_**
>>>
>>> igb.c?revision=248906&view=**markup
>>> http://svnweb.freebsd.org/**base/head/sys/dev/e1000/if_**
>>>
>>> igb.h?revision=248908&view=**markup
>>>
>>>
>>> I've applied these changes to latest 9.1-STABLE src and included the
>>> IGB_LEGACY_TX in the e1000 Makefile. So far I am not having any luck
>>> getting pfctl to think igb is supported.
>>>
>>> i.e. I am still getting the following when loading my PF config:
>>> pfctl -f /etc/pf.conf
>>> pfctl: igb0: driver does not support altq
>>>
>>> Can anyone comment on if the above referenced changes that Jack made
>>> should be sufficient to get ALTQ working with igb?
>>>
>>> The error is coming from src/contrib/pf/pfctl/pfctl.c. There seems to
>>> be a function that checks if the driver is supported or not but I
>>> cannot figure out why the ioctl is not returning a device.
>>>
>>> Here is the device check code for reference:
>>>
>>> int
>>> pfctl_add_altq(struct pfctl *pf, struct pf_altq *a)
>>> {
>>>   if (altqsupport &&
>>>   (loadopt & PFCTL_FLAG_ALTQ) != 0) {
>>>   memcpy(&pf->paltq->altq, a, sizeof(struct pf_altq));
>>>   if ((pf->opts & PF_OPT_NOACTION) == 0) {
>>>   if (ioctl(pf->dev, DIOCADDALTQ, pf->paltq)) {
>>>   if (errno == ENXIO)
>>>   errx(1, "qtype not
>>> configured");
>>>   else if (errno == ENODEV)
>>>   errx(1, "%s: driver does not
>>> support "
>>>   "altq", a->ifname);
>>>   else
>>>   err(1, "DIOCADDALTQ");
>>>   }
>>>   }
>>>   pfaltq_store(&pf->paltq->altq)**;
>>>
>>>   }
>>>   return (0);
>>> }
>>>
>>>
>>>
>>>
>>>
>>> On 28/03/2013 7:16 PM, Jack Vogel wrote:
>>>
>>> Have been kept fairly busy with other matters, one thing I could do short
>>> term is
>>> change the defines in igb the way I did in the em driver so you could
>>> still
>>> define
>>> the older if_start entry. Right now those are based on OS version and so
>>> you will
>>> automatically get if_transmit, but I could change it to be IGB_LEGACY_TX
>>> or
>>> so,
>>> and that could be defined in the Makefile.
>>>
>>> Would this help?
>>>
>>> Jack
>>>
>>>
>>> On Th

Re: igb and ALTQ in 9.1-rc3

[Karim Fodil-Lemelin]

Hi Nick,

Unfortunately I do not have a FBSD 9 box around where I can compile and 
test this so bear with me as this is pretty much straight out of looking 
at the source code directly (i.e it might not even compile).


But if your desperate please try the following (untested) patch (applied 
to stable/9):


diff --git a/sys/dev/e1000/if_igb.c b/sys/dev/e1000/if_igb.c
index 30bb052..3a6de2e 100644
--- a/sys/dev/e1000/if_igb.c
+++ b/sys/dev/e1000/if_igb.c
@@ -179,13 +179,13 @@ static int igb_detach(device_t);
 static int igb_shutdown(device_t);
 static int igb_suspend(device_t);
 static int igb_resume(device_t);
+static voidigb_start(struct ifnet *);
 #if __FreeBSD_version >= 80
 static int igb_mq_start(struct ifnet *, struct mbuf *);
 static int igb_mq_start_locked(struct ifnet *, struct tx_ring *);
 static voidigb_qflush(struct ifnet *);
 static voidigb_deferred_mq_start(void *, int);
 #else
-static voidigb_start(struct ifnet *);
 static voidigb_start_locked(struct tx_ring *, struct ifnet *ifp);
 #endif
 static int igb_ioctl(struct ifnet *, u_long, caddr_t);
@@ -377,7 +377,7 @@ SYSCTL_INT(_hw_igb, OID_AUTO, header_split, 
CTLFLAG_RDTUN, &igb_header_split, 0,

 ** This will autoconfigure based on
 ** the number of CPUs if left at 0.
 */
-static int igb_num_queues = 0;
+static int igb_num_queues = 1;
 TUNABLE_INT("hw.igb.num_queues", &igb_num_queues);
 SYSCTL_INT(_hw_igb, OID_AUTO, num_queues, CTLFLAG_RDTUN, 
&igb_num_queues, 0,

 "Number of queues to configure, 0 indicates autoconfigure");
@@ -926,6 +926,8 @@ igb_start_locked(struct tx_ring *txr, struct ifnet *ifp)
txr->queue_status |= IGB_QUEUE_WORKING;
}
 }
+
+#endif /* __FreeBSD_version < 80 */

 /*
  * Legacy TX driver routine, called from the
@@ -940,14 +942,17 @@ igb_start(struct ifnet *ifp)

if (ifp->if_drv_flags & IFF_DRV_RUNNING) {
IGB_TX_LOCK(txr);
+#if __FreeBSD_version < 80
+   igb_start_locked(txr, ifp);
+#else
+   igb_mq_start_locked(ifp, txr, NULL);
+#endif
igb_start_locked(txr, ifp);
IGB_TX_UNLOCK(txr);
}
return;
 }

-#else /* __FreeBSD_version >= 80 */
-
 /*
 ** Multiqueue Transmit Entry:
 **  quick turnaround to the stack
@@ -3089,12 +3094,11 @@ igb_setup_interface(device_t dev, struct adapter 
*adapter)

 #if __FreeBSD_version >= 80
ifp->if_transmit = igb_mq_start;
ifp->if_qflush = igb_qflush;
-#else
+#endif
ifp->if_start = igb_start;
IFQ_SET_MAXLEN(&ifp->if_snd, adapter->num_tx_desc - 1);
ifp->if_snd.ifq_drv_maxlen = adapter->num_tx_desc - 1;
IFQ_SET_READY(&ifp->if_snd);
-#endif

ether_ifattach(ifp, adapter->hw.mac.addr);



On 02/04/2013 9:58 AM, Nick Rogers wrote:

On Tuesday, April 2, 2013, Karim Fodil-Lemelin wrote:


Hi Nick,

Can you verify that you have at least one of those options in your kernel
config file:

ALTQ_CBQ
ALTQ_PRIQ
ALTQ_HFSC


Yes I have hfsc included in the kernel. I have other machines using altq
with em(4) interfaces and similar pf configurations on the same kernel that
work fine.



Regards,

Karim.

On 01/04/2013 8:22 PM, Nick Rogers wrote:

On Mon, Apr 1, 2013 at 8:44 AM, Karim Fodil-Lemelin
 wrote:

Hi Jack,

I think this would help M. Rogers case as we have done something similar
here to circumvent the issue and it seems to work well. I would also add
that when using ALTQ we found it much more stable to set the number of
queues to 1:

static int igb_num_queues = 1;

Our approach consisted in keeping igb_start() defined and using
igb_mq_start_locked() inside it instead of igb_start_locked().

Regards,

Karim.

Thanks for the pointer.

I've been working with Jack to get a fix for this in that downgrades
the stack to the older if_start/non-multiqueue interface. See the
following two commits he made to HEAD.

http://svnweb.freebsd.org/**base/head/sys/dev/e1000/if_**
igb.c?revision=248906&view=**markup
http://svnweb.freebsd.org/**base/head/sys/dev/e1000/if_**
igb.h?revision=248908&view=**markup

I've applied these changes to latest 9.1-STABLE src and included the
IGB_LEGACY_TX in the e1000 Makefile. So far I am not having any luck
getting pfctl to think igb is supported.

i.e. I am still getting the following when loading my PF config:
pfctl -f /etc/pf.conf
pfctl: igb0: driver does not support altq

Can anyone comment on if the above referenced changes that Jack made
should be sufficient to get ALTQ working with igb?

The error is coming from src/contrib/pf/pfctl/pfctl.c. There seems to
be a function that checks if the driver is supported or not but I
cannot figure out why the ioctl is not returning a device.

Here is the device check code for reference:

int
pfctl_add_altq(struct pfctl *pf, struct 

Re: igb and ALTQ in 9.1-rc3

[Karim Fodil-Lemelin]

Hi Nick,

You need to set the ALTQF_READY flag inside the igb driver. Make sure 
you have something like this in if_igb.c:


ifp->if_start = igb_start;
IFQ_SET_MAXLEN(&ifp->if_snd, adapter->num_tx_desc - 1);
ifp->if_snd.ifq_drv_maxlen = adapter->num_tx_desc - 1;
IFQ_SET_READY(&ifp->if_snd);

The call to IFQ_SET_READY() is what will enable ALTQ on your device.

Regards,

Karim.

On 02/04/2013 9:58 AM, Nick Rogers wrote:

On Tuesday, April 2, 2013, Karim Fodil-Lemelin wrote:


Hi Nick,

Can you verify that you have at least one of those options in your kernel
config file:

ALTQ_CBQ
ALTQ_PRIQ
ALTQ_HFSC


Yes I have hfsc included in the kernel. I have other machines using altq
with em(4) interfaces and similar pf configurations on the same kernel that
work fine.



Regards,

Karim.

On 01/04/2013 8:22 PM, Nick Rogers wrote:

On Mon, Apr 1, 2013 at 8:44 AM, Karim Fodil-Lemelin
 wrote:

Hi Jack,

I think this would help M. Rogers case as we have done something similar
here to circumvent the issue and it seems to work well. I would also add
that when using ALTQ we found it much more stable to set the number of
queues to 1:

static int igb_num_queues = 1;

Our approach consisted in keeping igb_start() defined and using
igb_mq_start_locked() inside it instead of igb_start_locked().

Regards,

Karim.

Thanks for the pointer.

I've been working with Jack to get a fix for this in that downgrades
the stack to the older if_start/non-multiqueue interface. See the
following two commits he made to HEAD.

http://svnweb.freebsd.org/**base/head/sys/dev/e1000/if_**
igb.c?revision=248906&view=**markup
http://svnweb.freebsd.org/**base/head/sys/dev/e1000/if_**
igb.h?revision=248908&view=**markup

I've applied these changes to latest 9.1-STABLE src and included the
IGB_LEGACY_TX in the e1000 Makefile. So far I am not having any luck
getting pfctl to think igb is supported.

i.e. I am still getting the following when loading my PF config:
pfctl -f /etc/pf.conf
pfctl: igb0: driver does not support altq

Can anyone comment on if the above referenced changes that Jack made
should be sufficient to get ALTQ working with igb?

The error is coming from src/contrib/pf/pfctl/pfctl.c. There seems to
be a function that checks if the driver is supported or not but I
cannot figure out why the ioctl is not returning a device.

Here is the device check code for reference:

int
pfctl_add_altq(struct pfctl *pf, struct pf_altq *a)
{
  if (altqsupport &&
  (loadopt & PFCTL_FLAG_ALTQ) != 0) {
  memcpy(&pf->paltq->altq, a, sizeof(struct pf_altq));
  if ((pf->opts & PF_OPT_NOACTION) == 0) {
  if (ioctl(pf->dev, DIOCADDALTQ, pf->paltq)) {
  if (errno == ENXIO)
  errx(1, "qtype not configured");
  else if (errno == ENODEV)
  errx(1, "%s: driver does not
support "
  "altq", a->ifname);
  else
  err(1, "DIOCADDALTQ");
  }
  }
  pfaltq_store(&pf->paltq->altq)**;
  }
  return (0);
}





On 28/03/2013 7:16 PM, Jack Vogel wrote:

Have been kept fairly busy with other matters, one thing I could do short
term is
change the defines in igb the way I did in the em driver so you could
still
define
the older if_start entry. Right now those are based on OS version and so
you will
automatically get if_transmit, but I could change it to be IGB_LEGACY_TX
or
so,
and that could be defined in the Makefile.

Would this help?

Jack


On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers  wrote:

  On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel  wrote:

On Mon, Dec 10, 2012 at 11:58 PM, Gleb Smirnoff 

wrote:

On Mon, Dec 10, 2012 at 03:31:19PM -0800, Jack Vogel wrote:
J> UH, maybe asking the owner of the driver would help :)
J>
J> ... and no, I've never been aware of doing anything to stop

supporting



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


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

Re: igb and ALTQ in 9.1-rc3

[Nick Rogers]

On Tuesday, April 2, 2013, Karim Fodil-Lemelin wrote:

> Hi Nick,
>
> Can you verify that you have at least one of those options in your kernel
> config file:
>
> ALTQ_CBQ
> ALTQ_PRIQ
> ALTQ_HFSC


Yes I have hfsc included in the kernel. I have other machines using altq
with em(4) interfaces and similar pf configurations on the same kernel that
work fine.


> Regards,
>
> Karim.
>
> On 01/04/2013 8:22 PM, Nick Rogers wrote:
>
> On Mon, Apr 1, 2013 at 8:44 AM, Karim Fodil-Lemelin
>  wrote:
>
> Hi Jack,
>
> I think this would help M. Rogers case as we have done something similar
> here to circumvent the issue and it seems to work well. I would also add
> that when using ALTQ we found it much more stable to set the number of
> queues to 1:
>
> static int igb_num_queues = 1;
>
> Our approach consisted in keeping igb_start() defined and using
> igb_mq_start_locked() inside it instead of igb_start_locked().
>
> Regards,
>
> Karim.
>
> Thanks for the pointer.
>
> I've been working with Jack to get a fix for this in that downgrades
> the stack to the older if_start/non-multiqueue interface. See the
> following two commits he made to HEAD.
>
> http://svnweb.freebsd.org/**base/head/sys/dev/e1000/if_**
> igb.c?revision=248906&view=**markup
> http://svnweb.freebsd.org/**base/head/sys/dev/e1000/if_**
> igb.h?revision=248908&view=**markup
>
> I've applied these changes to latest 9.1-STABLE src and included the
> IGB_LEGACY_TX in the e1000 Makefile. So far I am not having any luck
> getting pfctl to think igb is supported.
>
> i.e. I am still getting the following when loading my PF config:
> pfctl -f /etc/pf.conf
> pfctl: igb0: driver does not support altq
>
> Can anyone comment on if the above referenced changes that Jack made
> should be sufficient to get ALTQ working with igb?
>
> The error is coming from src/contrib/pf/pfctl/pfctl.c. There seems to
> be a function that checks if the driver is supported or not but I
> cannot figure out why the ioctl is not returning a device.
>
> Here is the device check code for reference:
>
> int
> pfctl_add_altq(struct pfctl *pf, struct pf_altq *a)
> {
>  if (altqsupport &&
>  (loadopt & PFCTL_FLAG_ALTQ) != 0) {
>  memcpy(&pf->paltq->altq, a, sizeof(struct pf_altq));
>  if ((pf->opts & PF_OPT_NOACTION) == 0) {
>  if (ioctl(pf->dev, DIOCADDALTQ, pf->paltq)) {
>  if (errno == ENXIO)
>  errx(1, "qtype not configured");
>  else if (errno == ENODEV)
>  errx(1, "%s: driver does not
> support "
>  "altq", a->ifname);
>  else
>  err(1, "DIOCADDALTQ");
>  }
>  }
>  pfaltq_store(&pf->paltq->altq)**;
>  }
>  return (0);
> }
>
>
>
>
>
> On 28/03/2013 7:16 PM, Jack Vogel wrote:
>
> Have been kept fairly busy with other matters, one thing I could do short
> term is
> change the defines in igb the way I did in the em driver so you could
> still
> define
> the older if_start entry. Right now those are based on OS version and so
> you will
> automatically get if_transmit, but I could change it to be IGB_LEGACY_TX
> or
> so,
> and that could be defined in the Makefile.
>
> Would this help?
>
> Jack
>
>
> On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers  wrote:
>
>  On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel  wrote:
>
> On Mon, Dec 10, 2012 at 11:58 PM, Gleb Smirnoff 
>
> wrote:
>
> On Mon, Dec 10, 2012 at 03:31:19PM -0800, Jack Vogel wrote:
> J> UH, maybe asking the owner of the driver would help :)
> J>
> J> ... and no, I've never been aware of doing anything to stop
>
> supporting
>
>
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: igb and ALTQ in 9.1-rc3

[Karim Fodil-Lemelin]

Hi Nick,

Can you verify that you have at least one of those options in your 
kernel config file:


ALTQ_CBQ
ALTQ_PRIQ
ALTQ_HFSC

Regards,

Karim.

On 01/04/2013 8:22 PM, Nick Rogers wrote:

On Mon, Apr 1, 2013 at 8:44 AM, Karim Fodil-Lemelin
 wrote:

Hi Jack,

I think this would help M. Rogers case as we have done something similar
here to circumvent the issue and it seems to work well. I would also add
that when using ALTQ we found it much more stable to set the number of
queues to 1:

static int igb_num_queues = 1;

Our approach consisted in keeping igb_start() defined and using
igb_mq_start_locked() inside it instead of igb_start_locked().

Regards,

Karim.

Thanks for the pointer.

I've been working with Jack to get a fix for this in that downgrades
the stack to the older if_start/non-multiqueue interface. See the
following two commits he made to HEAD.

http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_igb.c?revision=248906&view=markup
http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_igb.h?revision=248908&view=markup

I've applied these changes to latest 9.1-STABLE src and included the
IGB_LEGACY_TX in the e1000 Makefile. So far I am not having any luck
getting pfctl to think igb is supported.

i.e. I am still getting the following when loading my PF config:
pfctl -f /etc/pf.conf
pfctl: igb0: driver does not support altq

Can anyone comment on if the above referenced changes that Jack made
should be sufficient to get ALTQ working with igb?

The error is coming from src/contrib/pf/pfctl/pfctl.c. There seems to
be a function that checks if the driver is supported or not but I
cannot figure out why the ioctl is not returning a device.

Here is the device check code for reference:

int
pfctl_add_altq(struct pfctl *pf, struct pf_altq *a)
{
 if (altqsupport &&
 (loadopt & PFCTL_FLAG_ALTQ) != 0) {
 memcpy(&pf->paltq->altq, a, sizeof(struct pf_altq));
 if ((pf->opts & PF_OPT_NOACTION) == 0) {
 if (ioctl(pf->dev, DIOCADDALTQ, pf->paltq)) {
 if (errno == ENXIO)
 errx(1, "qtype not configured");
 else if (errno == ENODEV)
 errx(1, "%s: driver does not support "
 "altq", a->ifname);
 else
 err(1, "DIOCADDALTQ");
 }
 }
 pfaltq_store(&pf->paltq->altq);
 }
 return (0);
}






On 28/03/2013 7:16 PM, Jack Vogel wrote:

Have been kept fairly busy with other matters, one thing I could do short
term is
change the defines in igb the way I did in the em driver so you could
still
define
the older if_start entry. Right now those are based on OS version and so
you will
automatically get if_transmit, but I could change it to be IGB_LEGACY_TX
or
so,
and that could be defined in the Makefile.

Would this help?

Jack


On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers  wrote:


On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel  wrote:

On Mon, Dec 10, 2012 at 11:58 PM, Gleb Smirnoff 

wrote:

On Mon, Dec 10, 2012 at 03:31:19PM -0800, Jack Vogel wrote:
J> UH, maybe asking the owner of the driver would help :)
J>
J> ... and no, I've never been aware of doing anything to stop

supporting

altq
J> so you wouldn't see any commits. If there's something in the altq

code

or
J> support (which I have nothing to do with) that caused this no-one
informed
J> me.

Switching from if_start to if_transmit effectively disables ALTQ

support.

AFAIR, there is some magic implemented in other drivers that makes them
modern (that means using if_transmit), but still capable to switch to
queueing
mode if SIOCADDALTQ was casted upon them.



Oh, hmmm, I'll look into the matter after my vacation.

Jack

Has there been any progress on resolving this issue? I recently ran
into this problem upgrading my servers from 8.3 to 9.1-RELEASE and am
wondering what the latest recommendation is. I've used ALTQ and igb
successfully for years and it is unfortunate it no longer works.
Appreciate any advice.


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

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


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


___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To

Re: igb and ALTQ in 9.1-rc3

[Nick Rogers]

On Mon, Apr 1, 2013 at 8:44 AM, Karim Fodil-Lemelin
 wrote:
> Hi Jack,
>
> I think this would help M. Rogers case as we have done something similar
> here to circumvent the issue and it seems to work well. I would also add
> that when using ALTQ we found it much more stable to set the number of
> queues to 1:
>
> static int igb_num_queues = 1;
>
> Our approach consisted in keeping igb_start() defined and using
> igb_mq_start_locked() inside it instead of igb_start_locked().
>
> Regards,
>
> Karim.

Thanks for the pointer.

I've been working with Jack to get a fix for this in that downgrades
the stack to the older if_start/non-multiqueue interface. See the
following two commits he made to HEAD.

http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_igb.c?revision=248906&view=markup
http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_igb.h?revision=248908&view=markup

I've applied these changes to latest 9.1-STABLE src and included the
IGB_LEGACY_TX in the e1000 Makefile. So far I am not having any luck
getting pfctl to think igb is supported.

i.e. I am still getting the following when loading my PF config:
pfctl -f /etc/pf.conf
pfctl: igb0: driver does not support altq

Can anyone comment on if the above referenced changes that Jack made
should be sufficient to get ALTQ working with igb?

The error is coming from src/contrib/pf/pfctl/pfctl.c. There seems to
be a function that checks if the driver is supported or not but I
cannot figure out why the ioctl is not returning a device.

Here is the device check code for reference:

int
pfctl_add_altq(struct pfctl *pf, struct pf_altq *a)
{
if (altqsupport &&
(loadopt & PFCTL_FLAG_ALTQ) != 0) {
memcpy(&pf->paltq->altq, a, sizeof(struct pf_altq));
if ((pf->opts & PF_OPT_NOACTION) == 0) {
if (ioctl(pf->dev, DIOCADDALTQ, pf->paltq)) {
if (errno == ENXIO)
errx(1, "qtype not configured");
else if (errno == ENODEV)
errx(1, "%s: driver does not support "
"altq", a->ifname);
else
err(1, "DIOCADDALTQ");
}
}
pfaltq_store(&pf->paltq->altq);
}
return (0);
}



>
>
>
> On 28/03/2013 7:16 PM, Jack Vogel wrote:
>>
>> Have been kept fairly busy with other matters, one thing I could do short
>> term is
>> change the defines in igb the way I did in the em driver so you could
>> still
>> define
>> the older if_start entry. Right now those are based on OS version and so
>> you will
>> automatically get if_transmit, but I could change it to be IGB_LEGACY_TX
>> or
>> so,
>> and that could be defined in the Makefile.
>>
>> Would this help?
>>
>> Jack
>>
>>
>> On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers  wrote:
>>
>>> On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel  wrote:

 On Mon, Dec 10, 2012 at 11:58 PM, Gleb Smirnoff 
>>>
>>> wrote:
>
> On Mon, Dec 10, 2012 at 03:31:19PM -0800, Jack Vogel wrote:
> J> UH, maybe asking the owner of the driver would help :)
> J>
> J> ... and no, I've never been aware of doing anything to stop
>>>
>>> supporting
>
> altq
> J> so you wouldn't see any commits. If there's something in the altq
>>>
>>> code
>
> or
> J> support (which I have nothing to do with) that caused this no-one
> informed
> J> me.
>
> Switching from if_start to if_transmit effectively disables ALTQ
>>>
>>> support.
>
> AFAIR, there is some magic implemented in other drivers that makes them
> modern (that means using if_transmit), but still capable to switch to
> queueing
> mode if SIOCADDALTQ was casted upon them.
>
>
 Oh, hmmm, I'll look into the matter after my vacation.

 Jack
>>>
>>> Has there been any progress on resolving this issue? I recently ran
>>> into this problem upgrading my servers from 8.3 to 9.1-RELEASE and am
>>> wondering what the latest recommendation is. I've used ALTQ and igb
>>> successfully for years and it is unfortunate it no longer works.
>>> Appreciate any advice.
>>>
 ___
 freebsd-net@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-net
 To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
>>
>> ___
>> freebsd-net@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
>
>
> ___
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
__

Re: igb and ALTQ in 9.1-rc3

[Karim Fodil-Lemelin]

Hi Jack,

I think this would help M. Rogers case as we have done something similar 
here to circumvent the issue and it seems to work well. I would also add 
that when using ALTQ we found it much more stable to set the number of 
queues to 1:


static int igb_num_queues = 1;

Our approach consisted in keeping igb_start() defined and using 
igb_mq_start_locked() inside it instead of igb_start_locked().


Regards,

Karim.


On 28/03/2013 7:16 PM, Jack Vogel wrote:

Have been kept fairly busy with other matters, one thing I could do short
term is
change the defines in igb the way I did in the em driver so you could still
define
the older if_start entry. Right now those are based on OS version and so
you will
automatically get if_transmit, but I could change it to be IGB_LEGACY_TX or
so,
and that could be defined in the Makefile.

Would this help?

Jack


On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers  wrote:


On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel  wrote:

On Mon, Dec 10, 2012 at 11:58 PM, Gleb Smirnoff 

wrote:

On Mon, Dec 10, 2012 at 03:31:19PM -0800, Jack Vogel wrote:
J> UH, maybe asking the owner of the driver would help :)
J>
J> ... and no, I've never been aware of doing anything to stop

supporting

altq
J> so you wouldn't see any commits. If there's something in the altq

code

or
J> support (which I have nothing to do with) that caused this no-one
informed
J> me.

Switching from if_start to if_transmit effectively disables ALTQ

support.

AFAIR, there is some magic implemented in other drivers that makes them
modern (that means using if_transmit), but still capable to switch to
queueing
mode if SIOCADDALTQ was casted upon them.



Oh, hmmm, I'll look into the matter after my vacation.

Jack

Has there been any progress on resolving this issue? I recently ran
into this problem upgrading my servers from 8.3 to 9.1-RELEASE and am
wondering what the latest recommendation is. I've used ALTQ and igb
successfully for years and it is unfortunate it no longer works.
Appreciate any advice.


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

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


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

Re: igb and ALTQ in 9.1-rc3

[Adrian Chadd]

Barney,

As much as we'd like it, Jack's full time job involves other things
besides supporting FreeBSD.

If you want to see it done better, please work with the FreeBSD
developer community and improve the intel driver. No-one is stopping
you from stepping in.

In fact, this would be _beneficial_ to Jack's work inside Intel with
FreeBSD. If there is more of an active community participating with
the intel drivers and more companies choosing intel hardware for
FreeBSD network services, Intel will likely dump more effort into
FreeBSD.

So please, stop your non-constructive trolling and complaining and put
your skills to use for the greater good.

Sheesh. Intel have supplied a very thorough, detailed driver as well
as programming and errata datasheets for their chips. We aren't in the
dark here. There's more than enough rope to hang ourselves with.
Please focus on making it better.


Adrian


On 31 March 2013 05:35, Barney Cordoba  wrote:
> The reason that Jack is a no better programmer now than he was in 2009 might 
> have something to do with the fact that he hides when his work is criticized.
> Why not release the benchmarks you did while designing the igb driver, Jack? 
> Say what,you didn't do any benchmarking? How does the default driver perform, 
> say in a firewall,with 1000 user load? What's the optimum number of queues to 
> use in such a system?What's the effect of CPU binding? What's the effect with 
> multiple cards when you havemore queues than you have physical cpus?
> What made you decide to use buf_ring? Something new to play with?
> I'm guessing that you have no idea.
> BC--- On Fri, 3/29/13, Jack Vogel  wrote:
>
> From: Jack Vogel 
> Subject: Re: igb and ALTQ in 9.1-rc3
> To: "Pieper, Jeffrey E" 
> Cc: "Barney Cordoba" , "Nick Rogers" 
> , "freebsd-net@freebsd.org" , 
> "Clement Hermann (nodens)" 
> Date: Friday, March 29, 2013, 12:36 PM
>
> Fortunately, Barney doesn't speak for me, or for Intel, and I've long ago 
> realized its pointless to
> attempt anything like a fair conversation with him. The only thing he's ever 
> contributed is slander
>
> and pseudo-critique... another poison thread I'm done with.
>
> Jack
>
>
>
> On Fri, Mar 29, 2013 at 8:45 AM, Pieper, Jeffrey E 
>  wrote:
>
>
>
>
>
> -Original Message-
>
> From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-...@freebsd.org] On 
> Behalf Of Barney Cordoba
>
> Sent: Friday, March 29, 2013 5:51 AM
>
> To: Jack Vogel; Nick Rogers
>
> Cc: freebsd-net@freebsd.org; Clement Hermann (nodens)
>
> Subject: Re: igb and ALTQ in 9.1-rc3
>
>
>
>
>
>
>
> --- On Thu, 3/28/13, Nick Rogers  wrote:
>
>
>
>> From: Nick Rogers 
>
>> Subject: Re: igb and ALTQ in 9.1-rc3
>
>> To: "Jack Vogel" 
>
>> Cc: "Barney Cordoba" , "Clement Hermann (nodens)" 
>> , "freebsd-net@freebsd.org" 
>
>
>> Date: Thursday, March 28, 2013, 9:29 PM
>
>> On Thu, Mar 28, 2013 at 4:16 PM, Jack
>
>> Vogel 
>
>> wrote:
>
>> > Have been kept fairly busy with other matters, one
>
>> thing I could do short
>
>> > term is
>
>> > change the defines in igb the way I did in the em
>
>> driver so you could still
>
>> > define
>
>> > the older if_start entry. Right now those are based on
>
>> OS version and so you
>
>> > will
>
>> > automatically get if_transmit, but I could change it to
>
>> be IGB_LEGACY_TX or
>
>> > so,
>
>> > and that could be defined in the Makefile.
>
>> >
>
>> > Would this help?
>
>>
>
>> I'm currently using ALTQ successfully with the em driver, so
>
>> if igb
>
>> behaved the same with respect to using if_start instead of
>
>> if_transmit
>
>> when ALTQ is in play, that would be great. I do not
>
>> completely
>
>> understand the change you propose as I am not very familiar
>
>> with the
>
>> driver internals. Any kind of patch or extra
>
>> Makefile/make.conf
>
>> definition that would allow me to build a 9-STABLE kernel
>
>> with an igb
>
>> driver that works again with ALTQ, ASAP, would be much
>
>> appreciated.
>
>>
>
>> >
>
>> > Jack
>
>> >
>
>> >
>
>> >
>
>> > On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers 
>
>> wrote:
>
>> >>
>
>> >> On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel 
>
>> wrote:
>
>>

Re: igb and ALTQ in 9.1-rc3

[Barney Cordoba]

--- On Fri, 3/29/13, Adrian Chadd  wrote:

> From: Adrian Chadd 
> Subject: Re: igb and ALTQ in 9.1-rc3
> To: "Nick Rogers" 
> Cc: "Pieper, Jeffrey E" , 
> "freebsd-net@freebsd.org" , "Clement Hermann 
> (nodens)" , "Jack Vogel" 
> Date: Friday, March 29, 2013, 1:10 PM
> On 29 March 2013 10:04, Nick Rogers
> 
> wrote:
> 
> 
> > Multiqueue or not, I would appreciate any help with
> this thread's
> > original issue. Whether or not its the ideal thing to
> do, I cannot
> > simply just replace the NICs with an em(4) variant, as
> I have hundreds
> > of customers/systems already in production running 8.3
> and relying on
> > the igb driver + ALTQ. I need to be able to upgrade
> these systems to
> > 9.1 without making hardware changes.
> >
> >
> If it's that critical, have you thought about contracting
> out that task to
> a developer?

You have 100s of systems/customers using 1990s-class traffic shaping
and you have no programmer on staff with the skills to patch and test
an ethernet driver?

the igb driver has always sucked rocks, why did you use them in the first
place. Or did they just happen to be on the MB you use?

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

Re: igb and ALTQ in 9.1-rc3

[Barney Cordoba]

The reason that Jack is a no better programmer now than he was in 2009 might 
have something to do with the fact that he hides when his work is criticized. 
Why not release the benchmarks you did while designing the igb driver, Jack? 
Say what,you didn't do any benchmarking? How does the default driver perform, 
say in a firewall,with 1000 user load? What's the optimum number of queues to 
use in such a system?What's the effect of CPU binding? What's the effect with 
multiple cards when you havemore queues than you have physical cpus? 
What made you decide to use buf_ring? Something new to play with?
I'm guessing that you have no idea.
BC--- On Fri, 3/29/13, Jack Vogel  wrote:

From: Jack Vogel 
Subject: Re: igb and ALTQ in 9.1-rc3
To: "Pieper, Jeffrey E" 
Cc: "Barney Cordoba" , "Nick Rogers" 
, "freebsd-net@freebsd.org" , 
"Clement Hermann (nodens)" 
Date: Friday, March 29, 2013, 12:36 PM

Fortunately, Barney doesn't speak for me, or for Intel, and I've long ago 
realized its pointless to
attempt anything like a fair conversation with him. The only thing he's ever 
contributed is slander

and pseudo-critique... another poison thread I'm done with.

Jack



On Fri, Mar 29, 2013 at 8:45 AM, Pieper, Jeffrey E  
wrote:





-Original Message-

From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-...@freebsd.org] On 
Behalf Of Barney Cordoba

Sent: Friday, March 29, 2013 5:51 AM

To: Jack Vogel; Nick Rogers

Cc: freebsd-net@freebsd.org; Clement Hermann (nodens)

Subject: Re: igb and ALTQ in 9.1-rc3







--- On Thu, 3/28/13, Nick Rogers  wrote:



> From: Nick Rogers 

> Subject: Re: igb and ALTQ in 9.1-rc3

> To: "Jack Vogel" 

> Cc: "Barney Cordoba" , "Clement Hermann (nodens)" 
> , "freebsd-net@freebsd.org" 


> Date: Thursday, March 28, 2013, 9:29 PM

> On Thu, Mar 28, 2013 at 4:16 PM, Jack

> Vogel 

> wrote:

> > Have been kept fairly busy with other matters, one

> thing I could do short

> > term is

> > change the defines in igb the way I did in the em

> driver so you could still

> > define

> > the older if_start entry. Right now those are based on

> OS version and so you

> > will

> > automatically get if_transmit, but I could change it to

> be IGB_LEGACY_TX or

> > so,

> > and that could be defined in the Makefile.

> >

> > Would this help?

>

> I'm currently using ALTQ successfully with the em driver, so

> if igb

> behaved the same with respect to using if_start instead of

> if_transmit

> when ALTQ is in play, that would be great. I do not

> completely

> understand the change you propose as I am not very familiar

> with the

> driver internals. Any kind of patch or extra

> Makefile/make.conf

> definition that would allow me to build a 9-STABLE kernel

> with an igb

> driver that works again with ALTQ, ASAP, would be much

> appreciated.

>

> >

> > Jack

> >

> >

> >

> > On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers 

> wrote:

> >>

> >> On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel 

> wrote:

> >> > On Mon, Dec 10, 2012 at 11:58 PM, Gleb

> Smirnoff 

> >> > wrote:

> >> >

> >> >> On Mon, Dec 10, 2012 at 03:31:19PM -0800,

> Jack Vogel wrote:

> >> >> J> UH, maybe asking the owner of the

> driver would help :)

> >> >> J>

> >> >> J> ... and no, I've never been aware of

> doing anything to stop

> >> >> supporting

> >> >> altq

> >> >> J> so you wouldn't see any commits. If

> there's something in the altq

> >> >> code

> >> >> or

> >> >> J> support (which I have nothing to do

> with) that caused this no-one

> >> >> informed

> >> >> J> me.

> >> >>

> >> >> Switching from if_start to if_transmit

> effectively disables ALTQ

> >> >> support.

> >> >>

> >> >> AFAIR, there is some magic implemented in

> other drivers that makes them

> >> >> modern (that means using if_transmit), but

> still capable to switch to

> >> >> queueing

> >> >> mode if SIOCADDALTQ was casted upon them.

> >> >>

> >> >>

> >> > Oh, hmmm, I'll look into the matter after my

> vacation.

> >> >

> >> > Jack

> >>

> >> Has there been any progress on resolving this

> issue? I recently ran

> >> into this problem upgrading my servers from 

Re: igb and ALTQ in 9.1-rc3

[Barney Cordoba]

Do you know anything about the subject, Scott? I'd be interested in seeing your 
benchmarks with various queue counts, binding to cpus vs not binding, and the 
numbers comparing the pre multiqueue driver to the current one. It's the 
minimum that any marginally competent network driver developer would do.

Or are you just hurling insults because you're devoid of actual ideas?

BC


--- On Fri, 3/29/13, Scott Long  wrote:

> From: Scott Long 
> Subject: Re: igb and ALTQ in 9.1-rc3
> To: "Barney Cordoba" 
> Cc: "Nick Rogers" , "Adrian Chadd" , 
> "Jeffrey EPieper" , "freebsd-net@freebsd.org" 
> , "Clement Hermann (nodens)" , 
> "Jack Vogel" 
> Date: Friday, March 29, 2013, 12:42 PM
> Comedy gold.  It's been a while
> since I've seen this much idiocy from you, Barney. 
> Hopefully the rest of the mailing list will blackhole you,
> as I'm about to, and we can all get back to real work.
> 
> Scott
> 
> 
> 
> On Mar 29, 2013, at 10:38 AM, Barney Cordoba 
> wrote:
> 
> > it needs a lot more than a patch. It needs to be
> completely re-thunk
> > 
> > --- On Fri, 3/29/13, Adrian Chadd 
> wrote:
> > 
> > From: Adrian Chadd 
> > Subject: Re: igb and ALTQ in 9.1-rc3
> > To: "Barney Cordoba" 
> > Cc: "Jack Vogel" ,
> "Nick Rogers" ,
> "Jeffrey EPieper" ,
> "freebsd-net@freebsd.org"
> ,
> "Clement Hermann (nodens)" 
> > Date: Friday, March 29, 2013, 12:07 PM
> > 
> > Barney,
> > Patches gratefully accepted.
> > 
> > 
> > 
> > Adrian
> > 
> > 
> > 
> > On 29 March 2013 08:54, Barney Cordoba 
> wrote:
> > 
> > 
> > 
> > 
> > 
> > --- On Fri, 3/29/13, Pieper, Jeffrey E 
> wrote:
> > 
> > 
> > 
> >> From: Pieper, Jeffrey E 
> > 
> >> Subject: RE: igb and ALTQ in 9.1-rc3
> > 
> >> To: "Barney Cordoba" ,
> "Jack Vogel" ,
> "Nick Rogers" 
> > 
> > 
> >> Cc: "freebsd-net@freebsd.org"
> ,
> "Clement Hermann (nodens)" 
> > 
> > 
> >> Date: Friday, March 29, 2013, 11:45 AM
> > 
> >> 
> > 
> >> 
> > 
> >> -Original Message-
> > 
> >> From: owner-freebsd-...@freebsd.org
> > 
> >> [mailto:owner-freebsd-...@freebsd.org]
> > 
> >> On Behalf Of Barney Cordoba
> > 
> >> Sent: Friday, March 29, 2013 5:51 AM
> > 
> >> To: Jack Vogel; Nick Rogers
> > 
> >> Cc: freebsd-net@freebsd.org;
> > 
> >> Clement Hermann (nodens)
> > 
> >> Subject: Re: igb and ALTQ in 9.1-rc3
> > 
> >> 
> > 
> >> 
> > 
> >> 
> > 
> >> --- On Thu, 3/28/13, Nick Rogers 
> > 
> >> wrote:
> > 
> >> 
> > 
> >>> From: Nick Rogers 
> > 
> >>> Subject: Re: igb and ALTQ in 9.1-rc3
> > 
> >>> To: "Jack Vogel" 
> > 
> >>> Cc: "Barney Cordoba" ,
> > 
> >> "Clement Hermann (nodens)" ,
> > 
> >> "freebsd-net@freebsd.org"
> > 
> >> 
> > 
> >>> Date: Thursday, March 28, 2013, 9:29 PM
> > 
> >>> On Thu, Mar 28, 2013 at 4:16 PM, Jack
> > 
> >>> Vogel 
> > 
> >>> wrote:
> > 
> >>>> Have been kept fairly busy with other
> matters,
> > 
> >> one
> > 
> >>> thing I could do short
> > 
> >>>> term is
> > 
> >>>> change the defines in igb the way I did in
> the em
> > 
> >>> driver so you could still
> > 
> >>>> define
> > 
> >>>> the older if_start entry. Right now those
> are
> > 
> >> based on
> > 
> >>> OS version and so you
> > 
> >>>> will
> > 
> >>>> automatically get if_transmit, but I could
> change
> > 
> >> it to
> > 
> >>> be IGB_LEGACY_TX or
> > 
> >>>> so,
> > 
> >>>> and that could be defined in the Makefile.
> > 
> >>>> 
> > 
> >>>> Would this help?
> > 
> >>> 
> > 
> >>> I'm currently using ALTQ successfully with the
> em
> > 
> >> driver, so
> > 
> >>> if igb
> > 
> >>> behaved the s

Re: igb and ALTQ in 9.1-rc3

[Adrian Chadd]

On 29 March 2013 10:04, Nick Rogers  wrote:


> Multiqueue or not, I would appreciate any help with this thread's
> original issue. Whether or not its the ideal thing to do, I cannot
> simply just replace the NICs with an em(4) variant, as I have hundreds
> of customers/systems already in production running 8.3 and relying on
> the igb driver + ALTQ. I need to be able to upgrade these systems to
> 9.1 without making hardware changes.
>
>
If it's that critical, have you thought about contracting out that task to
a developer?



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

Re: igb and ALTQ in 9.1-rc3

[Nick Rogers]

On Fri, Mar 29, 2013 at 9:36 AM, Jack Vogel  wrote:
> Fortunately, Barney doesn't speak for me, or for Intel, and I've long ago
> realized its pointless to
> attempt anything like a fair conversation with him. The only thing he's ever
> contributed is slander
> and pseudo-critique... another poison thread I'm done with.
>
> Jack

Multiqueue or not, I would appreciate any help with this thread's
original issue. Whether or not its the ideal thing to do, I cannot
simply just replace the NICs with an em(4) variant, as I have hundreds
of customers/systems already in production running 8.3 and relying on
the igb driver + ALTQ. I need to be able to upgrade these systems to
9.1 without making hardware changes.

>
>
>
> On Fri, Mar 29, 2013 at 8:45 AM, Pieper, Jeffrey E
>  wrote:
>>
>>
>>
>> -Original Message-
>> From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-...@freebsd.org]
>> On Behalf Of Barney Cordoba
>> Sent: Friday, March 29, 2013 5:51 AM
>> To: Jack Vogel; Nick Rogers
>> Cc: freebsd-net@freebsd.org; Clement Hermann (nodens)
>> Subject: Re: igb and ALTQ in 9.1-rc3
>>
>>
>>
>> --- On Thu, 3/28/13, Nick Rogers  wrote:
>>
>> > From: Nick Rogers 
>> > Subject: Re: igb and ALTQ in 9.1-rc3
>> > To: "Jack Vogel" 
>> > Cc: "Barney Cordoba" , "Clement Hermann
>> > (nodens)" , "freebsd-net@freebsd.org"
>> > 
>> > Date: Thursday, March 28, 2013, 9:29 PM
>> > On Thu, Mar 28, 2013 at 4:16 PM, Jack
>> > Vogel 
>> > wrote:
>> > > Have been kept fairly busy with other matters, one
>> > thing I could do short
>> > > term is
>> > > change the defines in igb the way I did in the em
>> > driver so you could still
>> > > define
>> > > the older if_start entry. Right now those are based on
>> > OS version and so you
>> > > will
>> > > automatically get if_transmit, but I could change it to
>> > be IGB_LEGACY_TX or
>> > > so,
>> > > and that could be defined in the Makefile.
>> > >
>> > > Would this help?
>> >
>> > I'm currently using ALTQ successfully with the em driver, so
>> > if igb
>> > behaved the same with respect to using if_start instead of
>> > if_transmit
>> > when ALTQ is in play, that would be great. I do not
>> > completely
>> > understand the change you propose as I am not very familiar
>> > with the
>> > driver internals. Any kind of patch or extra
>> > Makefile/make.conf
>> > definition that would allow me to build a 9-STABLE kernel
>> > with an igb
>> > driver that works again with ALTQ, ASAP, would be much
>> > appreciated.
>> >
>> > >
>> > > Jack
>> > >
>> > >
>> > >
>> > > On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers 
>> > wrote:
>> > >>
>> > >> On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel 
>> > wrote:
>> > >> > On Mon, Dec 10, 2012 at 11:58 PM, Gleb
>> > Smirnoff 
>> > >> > wrote:
>> > >> >
>> > >> >> On Mon, Dec 10, 2012 at 03:31:19PM -0800,
>> > Jack Vogel wrote:
>> > >> >> J> UH, maybe asking the owner of the
>> > driver would help :)
>> > >> >> J>
>> > >> >> J> ... and no, I've never been aware of
>> > doing anything to stop
>> > >> >> supporting
>> > >> >> altq
>> > >> >> J> so you wouldn't see any commits. If
>> > there's something in the altq
>> > >> >> code
>> > >> >> or
>> > >> >> J> support (which I have nothing to do
>> > with) that caused this no-one
>> > >> >> informed
>> > >> >> J> me.
>> > >> >>
>> > >> >> Switching from if_start to if_transmit
>> > effectively disables ALTQ
>> > >> >> support.
>> > >> >>
>> > >> >> AFAIR, there is some magic implemented in
>> > other drivers that makes them
>> > >> >> modern (that means using if_transmit), but
>> > still capable to switch to
>> > >> >> queueing
>> > >> >> mode if SIOCADDALTQ was casted upon them.
>> > >> >>
>> >

Re: igb and ALTQ in 9.1-rc3

[Scott Long]

Comedy gold.  It's been a while since I've seen this much idiocy from you, 
Barney.  Hopefully the rest of the mailing list will blackhole you, as I'm 
about to, and we can all get back to real work.

Scott



On Mar 29, 2013, at 10:38 AM, Barney Cordoba  wrote:

> it needs a lot more than a patch. It needs to be completely re-thunk
> 
> --- On Fri, 3/29/13, Adrian Chadd  wrote:
> 
> From: Adrian Chadd 
> Subject: Re: igb and ALTQ in 9.1-rc3
> To: "Barney Cordoba" 
> Cc: "Jack Vogel" , "Nick Rogers" , 
> "Jeffrey EPieper" , "freebsd-net@freebsd.org" 
> , "Clement Hermann (nodens)" 
> Date: Friday, March 29, 2013, 12:07 PM
> 
> Barney,
> Patches gratefully accepted.
> 
> 
> 
> Adrian
> 
> 
> 
> On 29 March 2013 08:54, Barney Cordoba  wrote:
> 
> 
> 
> 
> 
> --- On Fri, 3/29/13, Pieper, Jeffrey E  wrote:
> 
> 
> 
>> From: Pieper, Jeffrey E 
> 
>> Subject: RE: igb and ALTQ in 9.1-rc3
> 
>> To: "Barney Cordoba" , "Jack Vogel" 
>> , "Nick Rogers" 
> 
> 
>> Cc: "freebsd-net@freebsd.org" , "Clement Hermann 
>> (nodens)" 
> 
> 
>> Date: Friday, March 29, 2013, 11:45 AM
> 
>> 
> 
>> 
> 
>> -----Original Message-----
> 
>> From: owner-freebsd-...@freebsd.org
> 
>> [mailto:owner-freebsd-...@freebsd.org]
> 
>> On Behalf Of Barney Cordoba
> 
>> Sent: Friday, March 29, 2013 5:51 AM
> 
>> To: Jack Vogel; Nick Rogers
> 
>> Cc: freebsd-net@freebsd.org;
> 
>> Clement Hermann (nodens)
> 
>> Subject: Re: igb and ALTQ in 9.1-rc3
> 
>> 
> 
>> 
> 
>> 
> 
>> --- On Thu, 3/28/13, Nick Rogers 
> 
>> wrote:
> 
>> 
> 
>>> From: Nick Rogers 
> 
>>> Subject: Re: igb and ALTQ in 9.1-rc3
> 
>>> To: "Jack Vogel" 
> 
>>> Cc: "Barney Cordoba" ,
> 
>> "Clement Hermann (nodens)" ,
> 
>> "freebsd-net@freebsd.org"
> 
>> 
> 
>>> Date: Thursday, March 28, 2013, 9:29 PM
> 
>>> On Thu, Mar 28, 2013 at 4:16 PM, Jack
> 
>>> Vogel 
> 
>>> wrote:
> 
>>>> Have been kept fairly busy with other matters,
> 
>> one
> 
>>> thing I could do short
> 
>>>> term is
> 
>>>> change the defines in igb the way I did in the em
> 
>>> driver so you could still
> 
>>>> define
> 
>>>> the older if_start entry. Right now those are
> 
>> based on
> 
>>> OS version and so you
> 
>>>> will
> 
>>>> automatically get if_transmit, but I could change
> 
>> it to
> 
>>> be IGB_LEGACY_TX or
> 
>>>> so,
> 
>>>> and that could be defined in the Makefile.
> 
>>>> 
> 
>>>> Would this help?
> 
>>> 
> 
>>> I'm currently using ALTQ successfully with the em
> 
>> driver, so
> 
>>> if igb
> 
>>> behaved the same with respect to using if_start instead
> 
>> of
> 
>>> if_transmit
> 
>>> when ALTQ is in play, that would be great. I do not
> 
>>> completely
> 
>>> understand the change you propose as I am not very
> 
>> familiar
> 
>>> with the
> 
>>> driver internals. Any kind of patch or extra
> 
>>> Makefile/make.conf
> 
>>> definition that would allow me to build a 9-STABLE
> 
>> kernel
> 
>>> with an igb
> 
>>> driver that works again with ALTQ, ASAP, would be much
> 
>>> appreciated.
> 
>>> 
> 
>>>> 
> 
>>>> Jack
> 
>>>> 
> 
>>>> 
> 
>>>> 
> 
>>>> On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers
> 
>> 
> 
>>> wrote:
> 
>>>>> 
> 
>>>>> On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel
> 
>> 
> 
>>> wrote:
> 
>>>>>> On Mon, Dec 10, 2012 at 11:58 PM, Gleb
> 
>>> Smirnoff 
> 
>>>>>> wrote:
> 
>>>>>> 
> 
>>>>>>> On Mon, Dec 10, 2012 at 03:31:19PM
> 
>> -0800,
> 
>>> Jack Vogel wrote:
> 
>>>>>>> J> UH, maybe asking the owner of
> 
>> the
> 
>>> driver would help :)
> 
>>>>>>> J>
> 
>>>>>>> J> ... and no, I've never been
> 
>> aware of
> 
>>> doing

Re: igb and ALTQ in 9.1-rc3

[Barney Cordoba]

it needs a lot more than a patch. It needs to be completely re-thunk

--- On Fri, 3/29/13, Adrian Chadd  wrote:

From: Adrian Chadd 
Subject: Re: igb and ALTQ in 9.1-rc3
To: "Barney Cordoba" 
Cc: "Jack Vogel" , "Nick Rogers" , 
"Jeffrey EPieper" , "freebsd-net@freebsd.org" 
, "Clement Hermann (nodens)" 
Date: Friday, March 29, 2013, 12:07 PM

Barney,
Patches gratefully accepted.



Adrian



On 29 March 2013 08:54, Barney Cordoba  wrote:





--- On Fri, 3/29/13, Pieper, Jeffrey E  wrote:



> From: Pieper, Jeffrey E 

> Subject: RE: igb and ALTQ in 9.1-rc3

> To: "Barney Cordoba" , "Jack Vogel" 
> , "Nick Rogers" 


> Cc: "freebsd-net@freebsd.org" , "Clement Hermann 
> (nodens)" 


> Date: Friday, March 29, 2013, 11:45 AM

>

>

> -Original Message-

> From: owner-freebsd-...@freebsd.org

> [mailto:owner-freebsd-...@freebsd.org]

> On Behalf Of Barney Cordoba

> Sent: Friday, March 29, 2013 5:51 AM

> To: Jack Vogel; Nick Rogers

> Cc: freebsd-net@freebsd.org;

> Clement Hermann (nodens)

> Subject: Re: igb and ALTQ in 9.1-rc3

>

>

>

> --- On Thu, 3/28/13, Nick Rogers 

> wrote:

>

> > From: Nick Rogers 

> > Subject: Re: igb and ALTQ in 9.1-rc3

> > To: "Jack Vogel" 

> > Cc: "Barney Cordoba" ,

> "Clement Hermann (nodens)" ,

> "freebsd-net@freebsd.org"

> 

> > Date: Thursday, March 28, 2013, 9:29 PM

> > On Thu, Mar 28, 2013 at 4:16 PM, Jack

> > Vogel 

> > wrote:

> > > Have been kept fairly busy with other matters,

> one

> > thing I could do short

> > > term is

> > > change the defines in igb the way I did in the em

> > driver so you could still

> > > define

> > > the older if_start entry. Right now those are

> based on

> > OS version and so you

> > > will

> > > automatically get if_transmit, but I could change

> it to

> > be IGB_LEGACY_TX or

> > > so,

> > > and that could be defined in the Makefile.

> > >

> > > Would this help?

> >

> > I'm currently using ALTQ successfully with the em

> driver, so

> > if igb

> > behaved the same with respect to using if_start instead

> of

> > if_transmit

> > when ALTQ is in play, that would be great. I do not

> > completely

> > understand the change you propose as I am not very

> familiar

> > with the

> > driver internals. Any kind of patch or extra

> > Makefile/make.conf

> > definition that would allow me to build a 9-STABLE

> kernel

> > with an igb

> > driver that works again with ALTQ, ASAP, would be much

> > appreciated.

> >

> > >

> > > Jack

> > >

> > >

> > >

> > > On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers

> 

> > wrote:

> > >>

> > >> On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel

> 

> > wrote:

> > >> > On Mon, Dec 10, 2012 at 11:58 PM, Gleb

> > Smirnoff 

> > >> > wrote:

> > >> >

> > >> >> On Mon, Dec 10, 2012 at 03:31:19PM

> -0800,

> > Jack Vogel wrote:

> > >> >> J> UH, maybe asking the owner of

> the

> > driver would help :)

> > >> >> J>

> > >> >> J> ... and no, I've never been

> aware of

> > doing anything to stop

> > >> >> supporting

> > >> >> altq

> > >> >> J> so you wouldn't see any

> commits. If

> > there's something in the altq

> > >> >> code

> > >> >> or

> > >> >> J> support (which I have nothing

> to do

> > with) that caused this no-one

> > >> >> informed

> > >> >> J> me.

> > >> >>

> > >> >> Switching from if_start to

> if_transmit

> > effectively disables ALTQ

> > >> >> support.

> > >> >>

> > >> >> AFAIR, there is some magic

> implemented in

> > other drivers that makes them

> > >> >> modern (that means using

> if_transmit), but

> > still capable to switch to

> > >> >> queueing

> > >> >> mode if SIOCADDALTQ was casted upon

> them.

> > >> >>

> > >> >>

> > >> > Oh, hmmm, I'll look into the matter after

> my

> > vacation.

> > >> >

> > >>

Re: igb and ALTQ in 9.1-rc3

[Jack Vogel]

Fortunately, Barney doesn't speak for me, or for Intel, and I've long ago
realized its pointless to
attempt anything like a fair conversation with him. The only thing he's
ever contributed is slander
and pseudo-critique... another poison thread I'm done with.

Jack



On Fri, Mar 29, 2013 at 8:45 AM, Pieper, Jeffrey E <
jeffrey.e.pie...@intel.com> wrote:

>
>
> -Original Message-
> From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-...@freebsd.org]
> On Behalf Of Barney Cordoba
> Sent: Friday, March 29, 2013 5:51 AM
> To: Jack Vogel; Nick Rogers
> Cc: freebsd-net@freebsd.org; Clement Hermann (nodens)
> Subject: Re: igb and ALTQ in 9.1-rc3
>
>
>
> --- On Thu, 3/28/13, Nick Rogers  wrote:
>
> > From: Nick Rogers 
> > Subject: Re: igb and ALTQ in 9.1-rc3
> > To: "Jack Vogel" 
> > Cc: "Barney Cordoba" , "Clement Hermann
> (nodens)" , "freebsd-net@freebsd.org" <
> freebsd-net@freebsd.org>
> > Date: Thursday, March 28, 2013, 9:29 PM
> > On Thu, Mar 28, 2013 at 4:16 PM, Jack
> > Vogel 
> > wrote:
> > > Have been kept fairly busy with other matters, one
> > thing I could do short
> > > term is
> > > change the defines in igb the way I did in the em
> > driver so you could still
> > > define
> > > the older if_start entry. Right now those are based on
> > OS version and so you
> > > will
> > > automatically get if_transmit, but I could change it to
> > be IGB_LEGACY_TX or
> > > so,
> > > and that could be defined in the Makefile.
> > >
> > > Would this help?
> >
> > I'm currently using ALTQ successfully with the em driver, so
> > if igb
> > behaved the same with respect to using if_start instead of
> > if_transmit
> > when ALTQ is in play, that would be great. I do not
> > completely
> > understand the change you propose as I am not very familiar
> > with the
> > driver internals. Any kind of patch or extra
> > Makefile/make.conf
> > definition that would allow me to build a 9-STABLE kernel
> > with an igb
> > driver that works again with ALTQ, ASAP, would be much
> > appreciated.
> >
> > >
> > > Jack
> > >
> > >
> > >
> > > On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers 
> > wrote:
> > >>
> > >> On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel 
> > wrote:
> > >> > On Mon, Dec 10, 2012 at 11:58 PM, Gleb
> > Smirnoff 
> > >> > wrote:
> > >> >
> > >> >> On Mon, Dec 10, 2012 at 03:31:19PM -0800,
> > Jack Vogel wrote:
> > >> >> J> UH, maybe asking the owner of the
> > driver would help :)
> > >> >> J>
> > >> >> J> ... and no, I've never been aware of
> > doing anything to stop
> > >> >> supporting
> > >> >> altq
> > >> >> J> so you wouldn't see any commits. If
> > there's something in the altq
> > >> >> code
> > >> >> or
> > >> >> J> support (which I have nothing to do
> > with) that caused this no-one
> > >> >> informed
> > >> >> J> me.
> > >> >>
> > >> >> Switching from if_start to if_transmit
> > effectively disables ALTQ
> > >> >> support.
> > >> >>
> > >> >> AFAIR, there is some magic implemented in
> > other drivers that makes them
> > >> >> modern (that means using if_transmit), but
> > still capable to switch to
> > >> >> queueing
> > >> >> mode if SIOCADDALTQ was casted upon them.
> > >> >>
> > >> >>
> > >> > Oh, hmmm, I'll look into the matter after my
> > vacation.
> > >> >
> > >> > Jack
> > >>
> > >> Has there been any progress on resolving this
> > issue? I recently ran
> > >> into this problem upgrading my servers from 8.3 to
> > 9.1-RELEASE and am
> > >> wondering what the latest recommendation is. I've
> > used ALTQ and igb
> > >> successfully for years and it is unfortunate it no
> > longer works.
> > >> Appreciate any advice.
> > >>
> >
> >Do yourself a favor and either get a cheap dual port 82571 card or
> >2 cards and disable the IGB ports. The igb driver is defective, and until
> >they back out the new, 

RE: igb and ALTQ in 9.1-rc3

[Barney Cordoba]

--- On Fri, 3/29/13, Pieper, Jeffrey E  wrote:

> From: Pieper, Jeffrey E 
> Subject: RE: igb and ALTQ in 9.1-rc3
> To: "Barney Cordoba" , "Jack Vogel" 
> , "Nick Rogers" 
> Cc: "freebsd-net@freebsd.org" , "Clement Hermann 
> (nodens)" 
> Date: Friday, March 29, 2013, 11:45 AM
> 
> 
> -Original Message-
> From: owner-freebsd-...@freebsd.org
> [mailto:owner-freebsd-...@freebsd.org]
> On Behalf Of Barney Cordoba
> Sent: Friday, March 29, 2013 5:51 AM
> To: Jack Vogel; Nick Rogers
> Cc: freebsd-net@freebsd.org;
> Clement Hermann (nodens)
> Subject: Re: igb and ALTQ in 9.1-rc3
> 
> 
> 
> --- On Thu, 3/28/13, Nick Rogers 
> wrote:
> 
> > From: Nick Rogers 
> > Subject: Re: igb and ALTQ in 9.1-rc3
> > To: "Jack Vogel" 
> > Cc: "Barney Cordoba" ,
> "Clement Hermann (nodens)" ,
> "freebsd-net@freebsd.org"
> 
> > Date: Thursday, March 28, 2013, 9:29 PM
> > On Thu, Mar 28, 2013 at 4:16 PM, Jack
> > Vogel 
> > wrote:
> > > Have been kept fairly busy with other matters,
> one
> > thing I could do short
> > > term is
> > > change the defines in igb the way I did in the em
> > driver so you could still
> > > define
> > > the older if_start entry. Right now those are
> based on
> > OS version and so you
> > > will
> > > automatically get if_transmit, but I could change
> it to
> > be IGB_LEGACY_TX or
> > > so,
> > > and that could be defined in the Makefile.
> > >
> > > Would this help?
> > 
> > I'm currently using ALTQ successfully with the em
> driver, so
> > if igb
> > behaved the same with respect to using if_start instead
> of
> > if_transmit
> > when ALTQ is in play, that would be great. I do not
> > completely
> > understand the change you propose as I am not very
> familiar
> > with the
> > driver internals. Any kind of patch or extra
> > Makefile/make.conf
> > definition that would allow me to build a 9-STABLE
> kernel
> > with an igb
> > driver that works again with ALTQ, ASAP, would be much
> > appreciated.
> > 
> > >
> > > Jack
> > >
> > >
> > >
> > > On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers
> 
> > wrote:
> > >>
> > >> On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel
> 
> > wrote:
> > >> > On Mon, Dec 10, 2012 at 11:58 PM, Gleb
> > Smirnoff 
> > >> > wrote:
> > >> >
> > >> >> On Mon, Dec 10, 2012 at 03:31:19PM
> -0800,
> > Jack Vogel wrote:
> > >> >> J> UH, maybe asking the owner of
> the
> > driver would help :)
> > >> >> J>
> > >> >> J> ... and no, I've never been
> aware of
> > doing anything to stop
> > >> >> supporting
> > >> >> altq
> > >> >> J> so you wouldn't see any
> commits. If
> > there's something in the altq
> > >> >> code
> > >> >> or
> > >> >> J> support (which I have nothing
> to do
> > with) that caused this no-one
> > >> >> informed
> > >> >> J> me.
> > >> >>
> > >> >> Switching from if_start to
> if_transmit
> > effectively disables ALTQ
> > >> >> support.
> > >> >>
> > >> >> AFAIR, there is some magic
> implemented in
> > other drivers that makes them
> > >> >> modern (that means using
> if_transmit), but
> > still capable to switch to
> > >> >> queueing
> > >> >> mode if SIOCADDALTQ was casted upon
> them.
> > >> >>
> > >> >>
> > >> > Oh, hmmm, I'll look into the matter after
> my
> > vacation.
> > >> >
> > >> > Jack
> > >>
> > >> Has there been any progress on resolving this
> > issue? I recently ran
> > >> into this problem upgrading my servers from
> 8.3 to
> > 9.1-RELEASE and am
> > >> wondering what the latest recommendation is.
> I've
> > used ALTQ and igb
> > >> successfully for years and it is unfortunate
> it no
> > longer works.
> > >> Appreciate any advice.
> > >>
> >
> >Do yourself a favor and either get a cheap dual port
> 82571 card or
> >2 cards and disable the I

Re: igb and ALTQ in 9.1-rc3

[Adrian Chadd]

Barney,

Patches gratefully accepted.




Adrian



On 29 March 2013 08:54, Barney Cordoba  wrote:

>
>
> --- On Fri, 3/29/13, Pieper, Jeffrey E  wrote:
>
> > From: Pieper, Jeffrey E 
> > Subject: RE: igb and ALTQ in 9.1-rc3
> > To: "Barney Cordoba" , "Jack Vogel" <
> jfvo...@gmail.com>, "Nick Rogers" 
> > Cc: "freebsd-net@freebsd.org" , "Clement
> Hermann (nodens)" 
> > Date: Friday, March 29, 2013, 11:45 AM
> >
> >
> > -Original Message-
> > From: owner-freebsd-...@freebsd.org
> > [mailto:owner-freebsd-...@freebsd.org]
> > On Behalf Of Barney Cordoba
> > Sent: Friday, March 29, 2013 5:51 AM
> > To: Jack Vogel; Nick Rogers
> > Cc: freebsd-net@freebsd.org;
> > Clement Hermann (nodens)
> > Subject: Re: igb and ALTQ in 9.1-rc3
> >
> >
> >
> > --- On Thu, 3/28/13, Nick Rogers 
> > wrote:
> >
> > > From: Nick Rogers 
> > > Subject: Re: igb and ALTQ in 9.1-rc3
> > > To: "Jack Vogel" 
> > > Cc: "Barney Cordoba" ,
> > "Clement Hermann (nodens)" ,
> > "freebsd-net@freebsd.org"
> > 
> > > Date: Thursday, March 28, 2013, 9:29 PM
> > > On Thu, Mar 28, 2013 at 4:16 PM, Jack
> > > Vogel 
> > > wrote:
> > > > Have been kept fairly busy with other matters,
> > one
> > > thing I could do short
> > > > term is
> > > > change the defines in igb the way I did in the em
> > > driver so you could still
> > > > define
> > > > the older if_start entry. Right now those are
> > based on
> > > OS version and so you
> > > > will
> > > > automatically get if_transmit, but I could change
> > it to
> > > be IGB_LEGACY_TX or
> > > > so,
> > > > and that could be defined in the Makefile.
> > > >
> > > > Would this help?
> > >
> > > I'm currently using ALTQ successfully with the em
> > driver, so
> > > if igb
> > > behaved the same with respect to using if_start instead
> > of
> > > if_transmit
> > > when ALTQ is in play, that would be great. I do not
> > > completely
> > > understand the change you propose as I am not very
> > familiar
> > > with the
> > > driver internals. Any kind of patch or extra
> > > Makefile/make.conf
> > > definition that would allow me to build a 9-STABLE
> > kernel
> > > with an igb
> > > driver that works again with ALTQ, ASAP, would be much
> > > appreciated.
> > >
> > > >
> > > > Jack
> > > >
> > > >
> > > >
> > > > On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers
> > 
> > > wrote:
> > > >>
> > > >> On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel
> > 
> > > wrote:
> > > >> > On Mon, Dec 10, 2012 at 11:58 PM, Gleb
> > > Smirnoff 
> > > >> > wrote:
> > > >> >
> > > >> >> On Mon, Dec 10, 2012 at 03:31:19PM
> > -0800,
> > > Jack Vogel wrote:
> > > >> >> J> UH, maybe asking the owner of
> > the
> > > driver would help :)
> > > >> >> J>
> > > >> >> J> ... and no, I've never been
> > aware of
> > > doing anything to stop
> > > >> >> supporting
> > > >> >> altq
> > > >> >> J> so you wouldn't see any
> > commits. If
> > > there's something in the altq
> > > >> >> code
> > > >> >> or
> > > >> >> J> support (which I have nothing
> > to do
> > > with) that caused this no-one
> > > >> >> informed
> > > >> >> J> me.
> > > >> >>
> > > >> >> Switching from if_start to
> > if_transmit
> > > effectively disables ALTQ
> > > >> >> support.
> > > >> >>
> > > >> >> AFAIR, there is some magic
> > implemented in
> > > other drivers that makes them
> > > >> >> modern (that means using
> > if_transmit), but
> > > still capable to switch to
> > > >> >> queueing
> > > >> >> mode if SIOCADDALTQ was casted upon
> > them.
> > > >> >>
> > > >> >>
&g

RE: igb and ALTQ in 9.1-rc3

[Barney Cordoba]

--- On Fri, 3/29/13, Pieper, Jeffrey E  wrote:

> From: Pieper, Jeffrey E 
> Subject: RE: igb and ALTQ in 9.1-rc3
> To: "Barney Cordoba" , "Jack Vogel" 
> , "Nick Rogers" 
> Cc: "freebsd-net@freebsd.org" , "Clement Hermann 
> (nodens)" 
> Date: Friday, March 29, 2013, 11:45 AM
> 
> 
> -Original Message-
> From: owner-freebsd-...@freebsd.org
> [mailto:owner-freebsd-...@freebsd.org]
> On Behalf Of Barney Cordoba
> Sent: Friday, March 29, 2013 5:51 AM
> To: Jack Vogel; Nick Rogers
> Cc: freebsd-net@freebsd.org;
> Clement Hermann (nodens)
> Subject: Re: igb and ALTQ in 9.1-rc3
> 
> 
> 
> --- On Thu, 3/28/13, Nick Rogers 
> wrote:
> 
> > From: Nick Rogers 
> > Subject: Re: igb and ALTQ in 9.1-rc3
> > To: "Jack Vogel" 
> > Cc: "Barney Cordoba" ,
> "Clement Hermann (nodens)" ,
> "freebsd-net@freebsd.org"
> 
> > Date: Thursday, March 28, 2013, 9:29 PM
> > On Thu, Mar 28, 2013 at 4:16 PM, Jack
> > Vogel 
> > wrote:
> > > Have been kept fairly busy with other matters,
> one
> > thing I could do short
> > > term is
> > > change the defines in igb the way I did in the em
> > driver so you could still
> > > define
> > > the older if_start entry. Right now those are
> based on
> > OS version and so you
> > > will
> > > automatically get if_transmit, but I could change
> it to
> > be IGB_LEGACY_TX or
> > > so,
> > > and that could be defined in the Makefile.
> > >
> > > Would this help?
> > 
> > I'm currently using ALTQ successfully with the em
> driver, so
> > if igb
> > behaved the same with respect to using if_start instead
> of
> > if_transmit
> > when ALTQ is in play, that would be great. I do not
> > completely
> > understand the change you propose as I am not very
> familiar
> > with the
> > driver internals. Any kind of patch or extra
> > Makefile/make.conf
> > definition that would allow me to build a 9-STABLE
> kernel
> > with an igb
> > driver that works again with ALTQ, ASAP, would be much
> > appreciated.
> > 
> > >
> > > Jack
> > >
> > >
> > >
> > > On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers
> 
> > wrote:
> > >>
> > >> On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel
> 
> > wrote:
> > >> > On Mon, Dec 10, 2012 at 11:58 PM, Gleb
> > Smirnoff 
> > >> > wrote:
> > >> >
> > >> >> On Mon, Dec 10, 2012 at 03:31:19PM
> -0800,
> > Jack Vogel wrote:
> > >> >> J> UH, maybe asking the owner of
> the
> > driver would help :)
> > >> >> J>
> > >> >> J> ... and no, I've never been
> aware of
> > doing anything to stop
> > >> >> supporting
> > >> >> altq
> > >> >> J> so you wouldn't see any
> commits. If
> > there's something in the altq
> > >> >> code
> > >> >> or
> > >> >> J> support (which I have nothing
> to do
> > with) that caused this no-one
> > >> >> informed
> > >> >> J> me.
> > >> >>
> > >> >> Switching from if_start to
> if_transmit
> > effectively disables ALTQ
> > >> >> support.
> > >> >>
> > >> >> AFAIR, there is some magic
> implemented in
> > other drivers that makes them
> > >> >> modern (that means using
> if_transmit), but
> > still capable to switch to
> > >> >> queueing
> > >> >> mode if SIOCADDALTQ was casted upon
> them.
> > >> >>
> > >> >>
> > >> > Oh, hmmm, I'll look into the matter after
> my
> > vacation.
> > >> >
> > >> > Jack
> > >>
> > >> Has there been any progress on resolving this
> > issue? I recently ran
> > >> into this problem upgrading my servers from
> 8.3 to
> > 9.1-RELEASE and am
> > >> wondering what the latest recommendation is.
> I've
> > used ALTQ and igb
> > >> successfully for years and it is unfortunate
> it no
> > longer works.
> > >> Appreciate any advice.
> > >>
> >
> >Do yourself a favor and either get a cheap dual port
> 82571 card or
> >2 cards and disable the IGB por

RE: igb and ALTQ in 9.1-rc3

[Pieper, Jeffrey E]

-Original Message-
From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-...@freebsd.org] On 
Behalf Of Barney Cordoba
Sent: Friday, March 29, 2013 5:51 AM
To: Jack Vogel; Nick Rogers
Cc: freebsd-net@freebsd.org; Clement Hermann (nodens)
Subject: Re: igb and ALTQ in 9.1-rc3



--- On Thu, 3/28/13, Nick Rogers  wrote:

> From: Nick Rogers 
> Subject: Re: igb and ALTQ in 9.1-rc3
> To: "Jack Vogel" 
> Cc: "Barney Cordoba" , "Clement Hermann (nodens)" 
> , "freebsd-net@freebsd.org" 
> Date: Thursday, March 28, 2013, 9:29 PM
> On Thu, Mar 28, 2013 at 4:16 PM, Jack
> Vogel 
> wrote:
> > Have been kept fairly busy with other matters, one
> thing I could do short
> > term is
> > change the defines in igb the way I did in the em
> driver so you could still
> > define
> > the older if_start entry. Right now those are based on
> OS version and so you
> > will
> > automatically get if_transmit, but I could change it to
> be IGB_LEGACY_TX or
> > so,
> > and that could be defined in the Makefile.
> >
> > Would this help?
> 
> I'm currently using ALTQ successfully with the em driver, so
> if igb
> behaved the same with respect to using if_start instead of
> if_transmit
> when ALTQ is in play, that would be great. I do not
> completely
> understand the change you propose as I am not very familiar
> with the
> driver internals. Any kind of patch or extra
> Makefile/make.conf
> definition that would allow me to build a 9-STABLE kernel
> with an igb
> driver that works again with ALTQ, ASAP, would be much
> appreciated.
> 
> >
> > Jack
> >
> >
> >
> > On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers 
> wrote:
> >>
> >> On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel 
> wrote:
> >> > On Mon, Dec 10, 2012 at 11:58 PM, Gleb
> Smirnoff 
> >> > wrote:
> >> >
> >> >> On Mon, Dec 10, 2012 at 03:31:19PM -0800,
> Jack Vogel wrote:
> >> >> J> UH, maybe asking the owner of the
> driver would help :)
> >> >> J>
> >> >> J> ... and no, I've never been aware of
> doing anything to stop
> >> >> supporting
> >> >> altq
> >> >> J> so you wouldn't see any commits. If
> there's something in the altq
> >> >> code
> >> >> or
> >> >> J> support (which I have nothing to do
> with) that caused this no-one
> >> >> informed
> >> >> J> me.
> >> >>
> >> >> Switching from if_start to if_transmit
> effectively disables ALTQ
> >> >> support.
> >> >>
> >> >> AFAIR, there is some magic implemented in
> other drivers that makes them
> >> >> modern (that means using if_transmit), but
> still capable to switch to
> >> >> queueing
> >> >> mode if SIOCADDALTQ was casted upon them.
> >> >>
> >> >>
> >> > Oh, hmmm, I'll look into the matter after my
> vacation.
> >> >
> >> > Jack
> >>
> >> Has there been any progress on resolving this
> issue? I recently ran
> >> into this problem upgrading my servers from 8.3 to
> 9.1-RELEASE and am
> >> wondering what the latest recommendation is. I've
> used ALTQ and igb
> >> successfully for years and it is unfortunate it no
> longer works.
> >> Appreciate any advice.
> >>
>
>Do yourself a favor and either get a cheap dual port 82571 card or
>2 cards and disable the IGB ports. The igb driver is defective, and until
>they back out the new, untested multi-queue stuff you're just neutering 
>your system trying to use it.
>
>Frankly this project made a huge mistake by moving forward with multi
>queue just for the sake of saying that you support it; without having
>any credible plan for implementing it. That nonsense that Bill Macy did
>should have been tarballed up and deposited in the trash folder. The
>biggest mess in programming history.
>
>That being said, the solution is not to hack the igb driver; its to make
>ALTQ if_transmit compatible, which shouldn't be all that difficult. 
>
>BC

I may be misunderstanding what you are saying, but if the solution is, as you 
say "not to hack the igb driver", then how is it defective in this case? Or are 
you just directing vitriol toward Intel? Multi-queue is working fine in igb. 

Jeff

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

Re: igb and ALTQ in 9.1-rc3

[Barney Cordoba]

--- On Thu, 3/28/13, Nick Rogers  wrote:

> From: Nick Rogers 
> Subject: Re: igb and ALTQ in 9.1-rc3
> To: "Jack Vogel" 
> Cc: "Barney Cordoba" , "Clement Hermann (nodens)" 
> , "freebsd-net@freebsd.org" 
> Date: Thursday, March 28, 2013, 9:29 PM
> On Thu, Mar 28, 2013 at 4:16 PM, Jack
> Vogel 
> wrote:
> > Have been kept fairly busy with other matters, one
> thing I could do short
> > term is
> > change the defines in igb the way I did in the em
> driver so you could still
> > define
> > the older if_start entry. Right now those are based on
> OS version and so you
> > will
> > automatically get if_transmit, but I could change it to
> be IGB_LEGACY_TX or
> > so,
> > and that could be defined in the Makefile.
> >
> > Would this help?
> 
> I'm currently using ALTQ successfully with the em driver, so
> if igb
> behaved the same with respect to using if_start instead of
> if_transmit
> when ALTQ is in play, that would be great. I do not
> completely
> understand the change you propose as I am not very familiar
> with the
> driver internals. Any kind of patch or extra
> Makefile/make.conf
> definition that would allow me to build a 9-STABLE kernel
> with an igb
> driver that works again with ALTQ, ASAP, would be much
> appreciated.
> 
> >
> > Jack
> >
> >
> >
> > On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers 
> wrote:
> >>
> >> On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel 
> wrote:
> >> > On Mon, Dec 10, 2012 at 11:58 PM, Gleb
> Smirnoff 
> >> > wrote:
> >> >
> >> >> On Mon, Dec 10, 2012 at 03:31:19PM -0800,
> Jack Vogel wrote:
> >> >> J> UH, maybe asking the owner of the
> driver would help :)
> >> >> J>
> >> >> J> ... and no, I've never been aware of
> doing anything to stop
> >> >> supporting
> >> >> altq
> >> >> J> so you wouldn't see any commits. If
> there's something in the altq
> >> >> code
> >> >> or
> >> >> J> support (which I have nothing to do
> with) that caused this no-one
> >> >> informed
> >> >> J> me.
> >> >>
> >> >> Switching from if_start to if_transmit
> effectively disables ALTQ
> >> >> support.
> >> >>
> >> >> AFAIR, there is some magic implemented in
> other drivers that makes them
> >> >> modern (that means using if_transmit), but
> still capable to switch to
> >> >> queueing
> >> >> mode if SIOCADDALTQ was casted upon them.
> >> >>
> >> >>
> >> > Oh, hmmm, I'll look into the matter after my
> vacation.
> >> >
> >> > Jack
> >>
> >> Has there been any progress on resolving this
> issue? I recently ran
> >> into this problem upgrading my servers from 8.3 to
> 9.1-RELEASE and am
> >> wondering what the latest recommendation is. I've
> used ALTQ and igb
> >> successfully for years and it is unfortunate it no
> longer works.
> >> Appreciate any advice.
> >>

Do yourself a favor and either get a cheap dual port 82571 card or
2 cards and disable the IGB ports. The igb driver is defective, and until
they back out the new, untested multi-queue stuff you're just neutering 
your system trying to use it.

Frankly this project made a huge mistake by moving forward with multi
queue just for the sake of saying that you support it; without having
any credible plan for implementing it. That nonsense that Bill Macy did
should have been tarballed up and deposited in the trash folder. The
biggest mess in programming history.

That being said, the solution is not to hack the igb driver; its to make
ALTQ if_transmit compatible, which shouldn't be all that difficult. 

BC


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

Re: igb and ALTQ in 9.1-rc3

[Nick Rogers]

On Thu, Mar 28, 2013 at 4:16 PM, Jack Vogel  wrote:
> Have been kept fairly busy with other matters, one thing I could do short
> term is
> change the defines in igb the way I did in the em driver so you could still
> define
> the older if_start entry. Right now those are based on OS version and so you
> will
> automatically get if_transmit, but I could change it to be IGB_LEGACY_TX or
> so,
> and that could be defined in the Makefile.
>
> Would this help?

I'm currently using ALTQ successfully with the em driver, so if igb
behaved the same with respect to using if_start instead of if_transmit
when ALTQ is in play, that would be great. I do not completely
understand the change you propose as I am not very familiar with the
driver internals. Any kind of patch or extra Makefile/make.conf
definition that would allow me to build a 9-STABLE kernel with an igb
driver that works again with ALTQ, ASAP, would be much appreciated.

>
> Jack
>
>
>
> On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers  wrote:
>>
>> On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel  wrote:
>> > On Mon, Dec 10, 2012 at 11:58 PM, Gleb Smirnoff 
>> > wrote:
>> >
>> >> On Mon, Dec 10, 2012 at 03:31:19PM -0800, Jack Vogel wrote:
>> >> J> UH, maybe asking the owner of the driver would help :)
>> >> J>
>> >> J> ... and no, I've never been aware of doing anything to stop
>> >> supporting
>> >> altq
>> >> J> so you wouldn't see any commits. If there's something in the altq
>> >> code
>> >> or
>> >> J> support (which I have nothing to do with) that caused this no-one
>> >> informed
>> >> J> me.
>> >>
>> >> Switching from if_start to if_transmit effectively disables ALTQ
>> >> support.
>> >>
>> >> AFAIR, there is some magic implemented in other drivers that makes them
>> >> modern (that means using if_transmit), but still capable to switch to
>> >> queueing
>> >> mode if SIOCADDALTQ was casted upon them.
>> >>
>> >>
>> > Oh, hmmm, I'll look into the matter after my vacation.
>> >
>> > Jack
>>
>> Has there been any progress on resolving this issue? I recently ran
>> into this problem upgrading my servers from 8.3 to 9.1-RELEASE and am
>> wondering what the latest recommendation is. I've used ALTQ and igb
>> successfully for years and it is unfortunate it no longer works.
>> Appreciate any advice.
>>
>> > ___
>> > freebsd-net@freebsd.org mailing list
>> > http://lists.freebsd.org/mailman/listinfo/freebsd-net
>> > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
>
>
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: igb and ALTQ in 9.1-rc3

[Jack Vogel]

Have been kept fairly busy with other matters, one thing I could do short
term is
change the defines in igb the way I did in the em driver so you could still
define
the older if_start entry. Right now those are based on OS version and so
you will
automatically get if_transmit, but I could change it to be IGB_LEGACY_TX or
so,
and that could be defined in the Makefile.

Would this help?

Jack


On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers  wrote:

> On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel  wrote:
> > On Mon, Dec 10, 2012 at 11:58 PM, Gleb Smirnoff 
> wrote:
> >
> >> On Mon, Dec 10, 2012 at 03:31:19PM -0800, Jack Vogel wrote:
> >> J> UH, maybe asking the owner of the driver would help :)
> >> J>
> >> J> ... and no, I've never been aware of doing anything to stop
> supporting
> >> altq
> >> J> so you wouldn't see any commits. If there's something in the altq
> code
> >> or
> >> J> support (which I have nothing to do with) that caused this no-one
> >> informed
> >> J> me.
> >>
> >> Switching from if_start to if_transmit effectively disables ALTQ
> support.
> >>
> >> AFAIR, there is some magic implemented in other drivers that makes them
> >> modern (that means using if_transmit), but still capable to switch to
> >> queueing
> >> mode if SIOCADDALTQ was casted upon them.
> >>
> >>
> > Oh, hmmm, I'll look into the matter after my vacation.
> >
> > Jack
>
> Has there been any progress on resolving this issue? I recently ran
> into this problem upgrading my servers from 8.3 to 9.1-RELEASE and am
> wondering what the latest recommendation is. I've used ALTQ and igb
> successfully for years and it is unfortunate it no longer works.
> Appreciate any advice.
>
> > ___
> > freebsd-net@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-net
> > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
>
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: igb and ALTQ in 9.1-rc3

[Nick Rogers]

On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel  wrote:
> On Mon, Dec 10, 2012 at 11:58 PM, Gleb Smirnoff  wrote:
>
>> On Mon, Dec 10, 2012 at 03:31:19PM -0800, Jack Vogel wrote:
>> J> UH, maybe asking the owner of the driver would help :)
>> J>
>> J> ... and no, I've never been aware of doing anything to stop supporting
>> altq
>> J> so you wouldn't see any commits. If there's something in the altq code
>> or
>> J> support (which I have nothing to do with) that caused this no-one
>> informed
>> J> me.
>>
>> Switching from if_start to if_transmit effectively disables ALTQ support.
>>
>> AFAIR, there is some magic implemented in other drivers that makes them
>> modern (that means using if_transmit), but still capable to switch to
>> queueing
>> mode if SIOCADDALTQ was casted upon them.
>>
>>
> Oh, hmmm, I'll look into the matter after my vacation.
>
> Jack

Has there been any progress on resolving this issue? I recently ran
into this problem upgrading my servers from 8.3 to 9.1-RELEASE and am
wondering what the latest recommendation is. I've used ALTQ and igb
successfully for years and it is unfortunate it no longer works.
Appreciate any advice.

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

Re: igb and ALTQ in 9.1-rc3

[Karim Fodil-Lemelin]

On 12/12/2012 2:49 AM, Ermal Luçi wrote:

On Tue, Dec 11, 2012 at 9:06 PM, Karim Fodil-Lemelin <
fodillemlinka...@gmail.com> wrote:


On 11/12/2012 11:27 AM, Ermal Luçi wrote:


On Tue, Dec 11, 2012 at 3:56 PM, Karim Fodil-Lemelin <
fodillemlinka...@gmail.com> wrote:

  On 11/12/2012 9:15 AM, Ermal Luçi wrote:

  On Tue, Dec 11, 2012 at 2:05 PM, Barney Cordoba <

barney_cord...@yahoo.com


**wrote:


  --- On Tue, 12/11/12, Gleb Smirnoff  wrote:

   From: Gleb Smirnoff 


Subject: Re: igb and ALTQ in 9.1-rc3
To: "Jack Vogel" 
Cc: "Clement Hermann (nodens)" , "Barney
Cordoba"

  , freebsd-net@FreeBSD.org

  Date: Tuesday, December 11, 2012, 2:58 AM

On Mon, Dec 10, 2012 at 03:31:19PM
-0800, Jack Vogel wrote:
J> UH, maybe asking the owner of the driver would help
:)
J>
J> ... and no, I've never been aware of doing anything to
stop supporting altq
J> so you wouldn't see any commits. If there's something
in the altq code or
J> support (which I have nothing to do with) that caused
this no-one informed
J> me.

Switching from if_start to if_transmit effectively disables
ALTQ support.

AFAIR, there is some magic implemented in other drivers that
makes them
modern (that means using if_transmit), but still capable to
switch to queueing
mode if SIOCADDALTQ was casted upon them.

   It seems pretty difficult to say that something is compatible with


something else if it hasn't been tested in a few years.

It seems to me that ATLQ is the one that should handle if_transmit.
although it's a good argument for having a raw "send" function in
drivers. Ethernet drivers don't need more than a send() routing that
loads a packet into the ring. The decision on what to do if you can't
queue a packet should be in the  network layer, if we must still call
things layers.

"start" is a leftover from a day when you stuffed a buffer and waited
for an interrupt to stuff in another. The whole idea is antiquated.

Imagine drivers that pull packets off of a card and simply queue it;
and that you simply submit a packet to be queued for transmit. Instead
of trying to find 35 programmers that understand all of the lock BS,
you only need to have a couple.

I always disable all of the gobbledegook like checksum offloading. They
just muddy the water and have very little effect on performance. A
modern
cpu can do a checksum as fast as you can manage the "capabilities"
without
disrupting the processing path.

With FreeBSD, every driver is an experience. Some suck so bad that they
should come with a warning. The MSK driver is completely useless, as
an example.


BC
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net<http://lists.freebsd.org/**mailman/listinfo/freebsd-net>
http://lists.freebsd.org/mailman/listinfo/freebsd-net>
To unsubscribe, send any mail to "freebsd-net-unsubscribe@**fre**
ebsd.org 
<http://freebsd.org>
"

   During implementation of if_transmit altq was not considered at all.


The default if_transmit provides some compatibility but that is void
since
altq has not been converted to call if_transmit after processing the
mbuf.

ALTQ can be adapted quite easily to if_transmit model it just wasn't
done
at the time.
With if_transmit model it can even be modularized and not be a compile
kernel option since the queue of the iface is abstracted now.

I have always wanted to do a diff but have not yet got to it.
The change is quite simple just provide an altq_transmit default method
and
just hook into if_transmit model on the fly.
You surely need to handle some iface events and enable altq based on
request but its is not a hard to implement.

I will always have this in my TODO but not sure when i can get to it.

   The issue is not only that igb doesn't support if_transmit or if_start


method but that ALTQ isn't multiqueue ready and still uses the IFQ_LOCK
for
all of its enqueue/dequeue operations. A simple drop in of if_transmit is
bound to cause race conditions on any multiqueue driver with ALTQ.

I do have a patch set for this on igb but its ugly and needs more work
although it should get you going. Let me know if your interested I will
clean it up and send it over. For more information on ALTQ discussion and
igb please read this thread: http://freebsd.1045724.n5.**
nabble.com/em-igb-if-transmit-drbr-and-ALTQ-td5760338.html<http://nabble.com/em-igb-if-transmit-**drbr-and-ALTQ-td5760338.html>
**<http://freebsd.1045724.n5.**nabble.com/em-igb-if-transmit-**
drbr-and-ALTQ-td5760338.html<http://freebsd.1045724.n5.nabble.com/em-igb-if-transmit-drbr-and-ALTQ-td5760338.html>
Best regards,

Karim.


  ALTQ needs to do serialization of packets to apply its policy.

While it can be extended to map driver queues to ALTQ queues that is not
easy done without getting s

Re: igb and ALTQ in 9.1-rc3

[Ermal Luçi]

On Tue, Dec 11, 2012 at 9:06 PM, Karim Fodil-Lemelin <
fodillemlinka...@gmail.com> wrote:

> On 11/12/2012 11:27 AM, Ermal Luçi wrote:
>
>> On Tue, Dec 11, 2012 at 3:56 PM, Karim Fodil-Lemelin <
>> fodillemlinka...@gmail.com> wrote:
>>
>>  On 11/12/2012 9:15 AM, Ermal Luçi wrote:
>>>
>>>  On Tue, Dec 11, 2012 at 2:05 PM, Barney Cordoba <
>>>> barney_cord...@yahoo.com
>>>>
>>>>> **wrote:
>>>>>
>>>>
>>>>  --- On Tue, 12/11/12, Gleb Smirnoff  wrote:
>>>>>
>>>>>   From: Gleb Smirnoff 
>>>>>
>>>>>> Subject: Re: igb and ALTQ in 9.1-rc3
>>>>>> To: "Jack Vogel" 
>>>>>> Cc: "Clement Hermann (nodens)" , "Barney
>>>>>> Cordoba"
>>>>>>
>>>>>>  , freebsd-net@FreeBSD.org
>>>>>
>>>>>  Date: Tuesday, December 11, 2012, 2:58 AM
>>>>>> On Mon, Dec 10, 2012 at 03:31:19PM
>>>>>> -0800, Jack Vogel wrote:
>>>>>> J> UH, maybe asking the owner of the driver would help
>>>>>> :)
>>>>>> J>
>>>>>> J> ... and no, I've never been aware of doing anything to
>>>>>> stop supporting altq
>>>>>> J> so you wouldn't see any commits. If there's something
>>>>>> in the altq code or
>>>>>> J> support (which I have nothing to do with) that caused
>>>>>> this no-one informed
>>>>>> J> me.
>>>>>>
>>>>>> Switching from if_start to if_transmit effectively disables
>>>>>> ALTQ support.
>>>>>>
>>>>>> AFAIR, there is some magic implemented in other drivers that
>>>>>> makes them
>>>>>> modern (that means using if_transmit), but still capable to
>>>>>> switch to queueing
>>>>>> mode if SIOCADDALTQ was casted upon them.
>>>>>>
>>>>>>   It seems pretty difficult to say that something is compatible with
>>>>>>
>>>>> something else if it hasn't been tested in a few years.
>>>>>
>>>>> It seems to me that ATLQ is the one that should handle if_transmit.
>>>>> although it's a good argument for having a raw "send" function in
>>>>> drivers. Ethernet drivers don't need more than a send() routing that
>>>>> loads a packet into the ring. The decision on what to do if you can't
>>>>> queue a packet should be in the  network layer, if we must still call
>>>>> things layers.
>>>>>
>>>>> "start" is a leftover from a day when you stuffed a buffer and waited
>>>>> for an interrupt to stuff in another. The whole idea is antiquated.
>>>>>
>>>>> Imagine drivers that pull packets off of a card and simply queue it;
>>>>> and that you simply submit a packet to be queued for transmit. Instead
>>>>> of trying to find 35 programmers that understand all of the lock BS,
>>>>> you only need to have a couple.
>>>>>
>>>>> I always disable all of the gobbledegook like checksum offloading. They
>>>>> just muddy the water and have very little effect on performance. A
>>>>> modern
>>>>> cpu can do a checksum as fast as you can manage the "capabilities"
>>>>> without
>>>>> disrupting the processing path.
>>>>>
>>>>> With FreeBSD, every driver is an experience. Some suck so bad that they
>>>>> should come with a warning. The MSK driver is completely useless, as
>>>>> an example.
>>>>>
>>>>>
>>>>> BC
>>>>> ___
>>>>> freebsd-net@freebsd.org mailing list
>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net<http://lists.freebsd.org/**mailman/listinfo/freebsd-net>
>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net>
>>>>> >
>>>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@**fre**
>>>>> ebsd.org 
>>>>> <http://freebsd.org>
>>>>> >
>>>>>
>>>>> "
>>>>>
>>>>>   During implementation of if_transmit a

Re: igb and ALTQ in 9.1-rc3

[Adrian Chadd]

On 11 December 2012 13:49, Andre Oppermann  wrote:

>> We -know- we need a much more generic implementation of packet queue
>> management. Someone just needs to come up with one. :-)
>
>
> As I've said earlier I'm working and cleaning up of the stack/driver
> interface and API.  It started out to better integrate the offload
> capabilities, reduce code duplication and to audit their usage in the
> drivers.  While doing that I've noticed, as others have, a couple more
> issues including the queuing problem.  So work is under way and by
> early next year a prototype for further discussion should be ready.

Sweet. Hopefully I'll have undone the rest of the if_start stuff in
net80211 by then.

I'm still stuck trying to figure out the right way to represent 802.11
fragments given how the net80211 stack was left before I inherited it.
ieee80211_fragment() creates a chain of mbufs representing the
fragment chain; I need to process those as an atomic entity rather
than a frame at a time.
Neither buf_ring nor if_queue are suitable for this.

I can serialise the frames coming into net80211 but until I figure out
a queue mechanism that lets me queue mbuf _chains_, I'll be stuck.

buf_ring is suitable with this, with some modifications (ie, checking
each mbuf is an mbuf list, rather than just calling m_freem() on the
single mbuf) but the ALQ bits kill that.

Thanks,


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

Re: igb and ALTQ in 9.1-rc3

[Andre Oppermann]

On 11.12.2012 22:36, Adrian Chadd wrote:

.. the ALTQ compatibility stuff for buf_ring and drbr_* is just plain ew.

The question is, who is going to step up and make that work? I'm
certainly not going to; when I teach net80211 and ath(4) about
if_transmit, I'm going to do it in a way that breaks ALTQ. And it'll
stay broken until I've ironed out all of the 802.11 and driver related
kinks that exist, and then it'll only come back up once we've all come
up with a much more sensible way to stuff this kind of queue
management into our network drivers.

We -know- we need a much more generic implementation of packet queue
management. Someone just needs to come up with one. :-)


As I've said earlier I'm working and cleaning up of the stack/driver
interface and API.  It started out to better integrate the offload
capabilities, reduce code duplication and to audit their usage in the
drivers.  While doing that I've noticed, as others have, a couple more
issues including the queuing problem.  So work is under way and by
early next year a prototype for further discussion should be ready.

--
Andre

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

Re: igb and ALTQ in 9.1-rc3

[Adrian Chadd]

.. the ALTQ compatibility stuff for buf_ring and drbr_* is just plain ew.

The question is, who is going to step up and make that work? I'm
certainly not going to; when I teach net80211 and ath(4) about
if_transmit, I'm going to do it in a way that breaks ALTQ. And it'll
stay broken until I've ironed out all of the 802.11 and driver related
kinks that exist, and then it'll only come back up once we've all come
up with a much more sensible way to stuff this kind of queue
management into our network drivers.

We -know- we need a much more generic implementation of packet queue
management. Someone just needs to come up with one. :-)



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

Re: igb and ALTQ in 9.1-rc3

[Karim Fodil-Lemelin]

On 11/12/2012 1:03 PM, Adrian Chadd wrote:

The if_transmit versus multiqueue thing is orthogonal.
Indeed, although ALTQ isn't using if_transmit and doing a simple drop in 
(replacing if_start with if_transmit) breaks ALTQ with multiqueue 
capable drivers.


I'm planning to make net80211 and ath(4) use if_transmit instead of
if_start. It won't be a multi-queue driver; I'm actually going down
the path of if_transmit specifically so I can control the TX queue
serialisation and actively _serialise_ frame TX, instead of
implementing a multi-queue driver.

ALTQ as a concept needs to be glued in a different way. It can't just
override the queue macros like it does. That's just plain ew.
I agree. I think ALTQ should maintain its own queues and locks and not 
rely on drivers for queue management.


net80211 has some rather quirky behaviour, unfortunately. I won't go
into it here. Suffice to say, I can't just use the IFQ macros, the
if_queue as it stands, nor buf_ring.



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


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

Re: igb and ALTQ in 9.1-rc3

[Karim Fodil-Lemelin]

On 11/12/2012 11:27 AM, Ermal Luçi wrote:

On Tue, Dec 11, 2012 at 3:56 PM, Karim Fodil-Lemelin <
fodillemlinka...@gmail.com> wrote:


On 11/12/2012 9:15 AM, Ermal Luçi wrote:


On Tue, Dec 11, 2012 at 2:05 PM, Barney Cordoba 
**wrote:



--- On Tue, 12/11/12, Gleb Smirnoff  wrote:

  From: Gleb Smirnoff 

Subject: Re: igb and ALTQ in 9.1-rc3
To: "Jack Vogel" 
Cc: "Clement Hermann (nodens)" , "Barney Cordoba"


, freebsd-net@FreeBSD.org


Date: Tuesday, December 11, 2012, 2:58 AM
On Mon, Dec 10, 2012 at 03:31:19PM
-0800, Jack Vogel wrote:
J> UH, maybe asking the owner of the driver would help
:)
J>
J> ... and no, I've never been aware of doing anything to
stop supporting altq
J> so you wouldn't see any commits. If there's something
in the altq code or
J> support (which I have nothing to do with) that caused
this no-one informed
J> me.

Switching from if_start to if_transmit effectively disables
ALTQ support.

AFAIR, there is some magic implemented in other drivers that
makes them
modern (that means using if_transmit), but still capable to
switch to queueing
mode if SIOCADDALTQ was casted upon them.

  It seems pretty difficult to say that something is compatible with

something else if it hasn't been tested in a few years.

It seems to me that ATLQ is the one that should handle if_transmit.
although it's a good argument for having a raw "send" function in
drivers. Ethernet drivers don't need more than a send() routing that
loads a packet into the ring. The decision on what to do if you can't
queue a packet should be in the  network layer, if we must still call
things layers.

"start" is a leftover from a day when you stuffed a buffer and waited
for an interrupt to stuff in another. The whole idea is antiquated.

Imagine drivers that pull packets off of a card and simply queue it;
and that you simply submit a packet to be queued for transmit. Instead
of trying to find 35 programmers that understand all of the lock BS,
you only need to have a couple.

I always disable all of the gobbledegook like checksum offloading. They
just muddy the water and have very little effect on performance. A modern
cpu can do a checksum as fast as you can manage the "capabilities"
without
disrupting the processing path.

With FreeBSD, every driver is an experience. Some suck so bad that they
should come with a warning. The MSK driver is completely useless, as
an example.


BC
__**_
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/**mailman/listinfo/freebsd-net<http://lists.freebsd.org/mailman/listinfo/freebsd-net>
To unsubscribe, send any mail to 
"freebsd-net-unsubscribe@**freebsd.org
"

  During implementation of if_transmit altq was not considered at all.

The default if_transmit provides some compatibility but that is void since
altq has not been converted to call if_transmit after processing the mbuf.

ALTQ can be adapted quite easily to if_transmit model it just wasn't done
at the time.
With if_transmit model it can even be modularized and not be a compile
kernel option since the queue of the iface is abstracted now.

I have always wanted to do a diff but have not yet got to it.
The change is quite simple just provide an altq_transmit default method
and
just hook into if_transmit model on the fly.
You surely need to handle some iface events and enable altq based on
request but its is not a hard to implement.

I will always have this in my TODO but not sure when i can get to it.

  The issue is not only that igb doesn't support if_transmit or if_start

method but that ALTQ isn't multiqueue ready and still uses the IFQ_LOCK for
all of its enqueue/dequeue operations. A simple drop in of if_transmit is
bound to cause race conditions on any multiqueue driver with ALTQ.

I do have a patch set for this on igb but its ugly and needs more work
although it should get you going. Let me know if your interested I will
clean it up and send it over. For more information on ALTQ discussion and
igb please read this thread: http://freebsd.1045724.n5.**
nabble.com/em-igb-if-transmit-**drbr-and-ALTQ-td5760338.html<http://freebsd.1045724.n5.nabble.com/em-igb-if-transmit-drbr-and-ALTQ-td5760338.html>

Best regards,

Karim.



ALTQ needs to do serialization of packets to apply its policy.
While it can be extended to map driver queues to ALTQ queues that is not
easy done without getting some interface to the driver to communicate.
The poor man implementation would be to pass an index argument when calling
driver transmit routine.

I doubt it is realistic to map ALTQ queues to driver queues since ALTQ 
can have many more queues then what any driver would need and those 
queues are controlled by users in so many ways it is almost impossible 
to cater for all cases in all device drivers. This could lead to TX 
rings being quickly filled 

Re: igb and ALTQ in 9.1-rc3

[Adrian Chadd]

The if_transmit versus multiqueue thing is orthogonal.

I'm planning to make net80211 and ath(4) use if_transmit instead of
if_start. It won't be a multi-queue driver; I'm actually going down
the path of if_transmit specifically so I can control the TX queue
serialisation and actively _serialise_ frame TX, instead of
implementing a multi-queue driver.

ALTQ as a concept needs to be glued in a different way. It can't just
override the queue macros like it does. That's just plain ew.

net80211 has some rather quirky behaviour, unfortunately. I won't go
into it here. Suffice to say, I can't just use the IFQ macros, the
if_queue as it stands, nor buf_ring.



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

Re: igb and ALTQ in 9.1-rc3

[Ermal Luçi]

On Tue, Dec 11, 2012 at 3:56 PM, Karim Fodil-Lemelin <
fodillemlinka...@gmail.com> wrote:

> On 11/12/2012 9:15 AM, Ermal Luçi wrote:
>
>> On Tue, Dec 11, 2012 at 2:05 PM, Barney Cordoba > >**wrote:
>>
>>
>>> --- On Tue, 12/11/12, Gleb Smirnoff  wrote:
>>>
>>>  From: Gleb Smirnoff 
>>>> Subject: Re: igb and ALTQ in 9.1-rc3
>>>> To: "Jack Vogel" 
>>>> Cc: "Clement Hermann (nodens)" , "Barney Cordoba"
>>>>
>>> , freebsd-net@FreeBSD.org
>>>
>>>> Date: Tuesday, December 11, 2012, 2:58 AM
>>>> On Mon, Dec 10, 2012 at 03:31:19PM
>>>> -0800, Jack Vogel wrote:
>>>> J> UH, maybe asking the owner of the driver would help
>>>> :)
>>>> J>
>>>> J> ... and no, I've never been aware of doing anything to
>>>> stop supporting altq
>>>> J> so you wouldn't see any commits. If there's something
>>>> in the altq code or
>>>> J> support (which I have nothing to do with) that caused
>>>> this no-one informed
>>>> J> me.
>>>>
>>>> Switching from if_start to if_transmit effectively disables
>>>> ALTQ support.
>>>>
>>>> AFAIR, there is some magic implemented in other drivers that
>>>> makes them
>>>> modern (that means using if_transmit), but still capable to
>>>> switch to queueing
>>>> mode if SIOCADDALTQ was casted upon them.
>>>>
>>>>  It seems pretty difficult to say that something is compatible with
>>> something else if it hasn't been tested in a few years.
>>>
>>> It seems to me that ATLQ is the one that should handle if_transmit.
>>> although it's a good argument for having a raw "send" function in
>>> drivers. Ethernet drivers don't need more than a send() routing that
>>> loads a packet into the ring. The decision on what to do if you can't
>>> queue a packet should be in the  network layer, if we must still call
>>> things layers.
>>>
>>> "start" is a leftover from a day when you stuffed a buffer and waited
>>> for an interrupt to stuff in another. The whole idea is antiquated.
>>>
>>> Imagine drivers that pull packets off of a card and simply queue it;
>>> and that you simply submit a packet to be queued for transmit. Instead
>>> of trying to find 35 programmers that understand all of the lock BS,
>>> you only need to have a couple.
>>>
>>> I always disable all of the gobbledegook like checksum offloading. They
>>> just muddy the water and have very little effect on performance. A modern
>>> cpu can do a checksum as fast as you can manage the "capabilities"
>>> without
>>> disrupting the processing path.
>>>
>>> With FreeBSD, every driver is an experience. Some suck so bad that they
>>> should come with a warning. The MSK driver is completely useless, as
>>> an example.
>>>
>>>
>>> BC
>>> __**_
>>> freebsd-net@freebsd.org mailing list
>>> http://lists.freebsd.org/**mailman/listinfo/freebsd-net<http://lists.freebsd.org/mailman/listinfo/freebsd-net>
>>> To unsubscribe, send any mail to 
>>> "freebsd-net-unsubscribe@**freebsd.org
>>> "
>>>
>>>  During implementation of if_transmit altq was not considered at all.
>> The default if_transmit provides some compatibility but that is void since
>> altq has not been converted to call if_transmit after processing the mbuf.
>>
>> ALTQ can be adapted quite easily to if_transmit model it just wasn't done
>> at the time.
>> With if_transmit model it can even be modularized and not be a compile
>> kernel option since the queue of the iface is abstracted now.
>>
>> I have always wanted to do a diff but have not yet got to it.
>> The change is quite simple just provide an altq_transmit default method
>> and
>> just hook into if_transmit model on the fly.
>> You surely need to handle some iface events and enable altq based on
>> request but its is not a hard to implement.
>>
>> I will always have this in my TODO but not sure when i can get to it.
>>
>>  The issue is not only that igb doesn't support if_transmit or if_start
> method but that ALTQ isn't multiqueue ready and still uses the IFQ_LOCK for
> all of its enqueue/dequeue operations. A simple dr

Re: igb and ALTQ in 9.1-rc3

[Barney Cordoba]

--- On Tue, 12/11/12, Karim Fodil-Lemelin  wrote:

> From: Karim Fodil-Lemelin 
> Subject: Re: igb and ALTQ in 9.1-rc3
> To: freebsd-net@freebsd.org
> Cc: nodens2...@gmail.com
> Date: Tuesday, December 11, 2012, 9:56 AM
> On 11/12/2012 9:15 AM, Ermal Luçi
> wrote:
> > On Tue, Dec 11, 2012 at 2:05 PM, Barney Cordoba 
> > wrote:
> >
> >>
> >> --- On Tue, 12/11/12, Gleb Smirnoff 
> wrote:
> >>
> >>> From: Gleb Smirnoff 
> >>> Subject: Re: igb and ALTQ in 9.1-rc3
> >>> To: "Jack Vogel" 
> >>> Cc: "Clement Hermann (nodens)" ,
> "Barney Cordoba"
> >> ,
> freebsd-net@FreeBSD.org
> >>> Date: Tuesday, December 11, 2012, 2:58 AM
> >>> On Mon, Dec 10, 2012 at 03:31:19PM
> >>> -0800, Jack Vogel wrote:
> >>> J> UH, maybe asking the owner of the driver
> would help
> >>> :)
> >>> J>
> >>> J> ... and no, I've never been aware of
> doing anything to
> >>> stop supporting altq
> >>> J> so you wouldn't see any commits. If
> there's something
> >>> in the altq code or
> >>> J> support (which I have nothing to do with)
> that caused
> >>> this no-one informed
> >>> J> me.
> >>>
> >>> Switching from if_start to if_transmit
> effectively disables
> >>> ALTQ support.
> >>>
> >>> AFAIR, there is some magic implemented in other
> drivers that
> >>> makes them
> >>> modern (that means using if_transmit), but
> still capable to
> >>> switch to queueing
> >>> mode if SIOCADDALTQ was casted upon them.
> >>>
> >> It seems pretty difficult to say that something is
> compatible with
> >> something else if it hasn't been tested in a few
> years.
> >>
> >> It seems to me that ATLQ is the one that should
> handle if_transmit.
> >> although it's a good argument for having a raw
> "send" function in
> >> drivers. Ethernet drivers don't need more than a
> send() routing that
> >> loads a packet into the ring. The decision on what
> to do if you can't
> >> queue a packet should be in the  network
> layer, if we must still call
> >> things layers.
> >>
> >> "start" is a leftover from a day when you stuffed a
> buffer and waited
> >> for an interrupt to stuff in another. The whole
> idea is antiquated.
> >>
> >> Imagine drivers that pull packets off of a card and
> simply queue it;
> >> and that you simply submit a packet to be queued
> for transmit. Instead
> >> of trying to find 35 programmers that understand
> all of the lock BS,
> >> you only need to have a couple.
> >>
> >> I always disable all of the gobbledegook like
> checksum offloading. They
> >> just muddy the water and have very little effect on
> performance. A modern
> >> cpu can do a checksum as fast as you can manage the
> "capabilities" without
> >> disrupting the processing path.
> >>
> >> With FreeBSD, every driver is an experience. Some
> suck so bad that they
> >> should come with a warning. The MSK driver is
> completely useless, as
> >> an example.
> >>
> >>
> >> BC
> >> ___
> >> freebsd-net@freebsd.org
> mailing list
> >> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> >> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
> >>
> > During implementation of if_transmit altq was not
> considered at all.
> > The default if_transmit provides some compatibility but
> that is void since
> > altq has not been converted to call if_transmit after
> processing the mbuf.
> >
> > ALTQ can be adapted quite easily to if_transmit model
> it just wasn't done
> > at the time.
> > With if_transmit model it can even be modularized and
> not be a compile
> > kernel option since the queue of the iface is
> abstracted now.
> >
> > I have always wanted to do a diff but have not yet got
> to it.
> > The change is quite simple just provide an
> altq_transmit default method and
> > just hook into if_transmit model on the fly.
> > You surely need to handle some iface events and enable
> altq based on
> > request but its is not a hard to implement.
> >
> >

Re: igb and ALTQ in 9.1-rc3

[Karim Fodil-Lemelin]

On 11/12/2012 9:15 AM, Ermal Luçi wrote:

On Tue, Dec 11, 2012 at 2:05 PM, Barney Cordoba wrote:



--- On Tue, 12/11/12, Gleb Smirnoff  wrote:


From: Gleb Smirnoff 
Subject: Re: igb and ALTQ in 9.1-rc3
To: "Jack Vogel" 
Cc: "Clement Hermann (nodens)" , "Barney Cordoba"

, freebsd-net@FreeBSD.org

Date: Tuesday, December 11, 2012, 2:58 AM
On Mon, Dec 10, 2012 at 03:31:19PM
-0800, Jack Vogel wrote:
J> UH, maybe asking the owner of the driver would help
:)
J>
J> ... and no, I've never been aware of doing anything to
stop supporting altq
J> so you wouldn't see any commits. If there's something
in the altq code or
J> support (which I have nothing to do with) that caused
this no-one informed
J> me.

Switching from if_start to if_transmit effectively disables
ALTQ support.

AFAIR, there is some magic implemented in other drivers that
makes them
modern (that means using if_transmit), but still capable to
switch to queueing
mode if SIOCADDALTQ was casted upon them.


It seems pretty difficult to say that something is compatible with
something else if it hasn't been tested in a few years.

It seems to me that ATLQ is the one that should handle if_transmit.
although it's a good argument for having a raw "send" function in
drivers. Ethernet drivers don't need more than a send() routing that
loads a packet into the ring. The decision on what to do if you can't
queue a packet should be in the  network layer, if we must still call
things layers.

"start" is a leftover from a day when you stuffed a buffer and waited
for an interrupt to stuff in another. The whole idea is antiquated.

Imagine drivers that pull packets off of a card and simply queue it;
and that you simply submit a packet to be queued for transmit. Instead
of trying to find 35 programmers that understand all of the lock BS,
you only need to have a couple.

I always disable all of the gobbledegook like checksum offloading. They
just muddy the water and have very little effect on performance. A modern
cpu can do a checksum as fast as you can manage the "capabilities" without
disrupting the processing path.

With FreeBSD, every driver is an experience. Some suck so bad that they
should come with a warning. The MSK driver is completely useless, as
an example.


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


During implementation of if_transmit altq was not considered at all.
The default if_transmit provides some compatibility but that is void since
altq has not been converted to call if_transmit after processing the mbuf.

ALTQ can be adapted quite easily to if_transmit model it just wasn't done
at the time.
With if_transmit model it can even be modularized and not be a compile
kernel option since the queue of the iface is abstracted now.

I have always wanted to do a diff but have not yet got to it.
The change is quite simple just provide an altq_transmit default method and
just hook into if_transmit model on the fly.
You surely need to handle some iface events and enable altq based on
request but its is not a hard to implement.

I will always have this in my TODO but not sure when i can get to it.

The issue is not only that igb doesn't support if_transmit or if_start 
method but that ALTQ isn't multiqueue ready and still uses the IFQ_LOCK 
for all of its enqueue/dequeue operations. A simple drop in of 
if_transmit is bound to cause race conditions on any multiqueue driver 
with ALTQ.


I do have a patch set for this on igb but its ugly and needs more work 
although it should get you going. Let me know if your interested I will 
clean it up and send it over. For more information on ALTQ discussion 
and igb please read this thread: 
http://freebsd.1045724.n5.nabble.com/em-igb-if-transmit-drbr-and-ALTQ-td5760338.html


Best regards,

Karim.


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

Re: igb and ALTQ in 9.1-rc3

[Ermal Luçi]

On Tue, Dec 11, 2012 at 2:05 PM, Barney Cordoba wrote:

>
>
> --- On Tue, 12/11/12, Gleb Smirnoff  wrote:
>
> > From: Gleb Smirnoff 
> > Subject: Re: igb and ALTQ in 9.1-rc3
> > To: "Jack Vogel" 
> > Cc: "Clement Hermann (nodens)" , "Barney Cordoba"
> , freebsd-net@FreeBSD.org
> > Date: Tuesday, December 11, 2012, 2:58 AM
> > On Mon, Dec 10, 2012 at 03:31:19PM
> > -0800, Jack Vogel wrote:
> > J> UH, maybe asking the owner of the driver would help
> > :)
> > J>
> > J> ... and no, I've never been aware of doing anything to
> > stop supporting altq
> > J> so you wouldn't see any commits. If there's something
> > in the altq code or
> > J> support (which I have nothing to do with) that caused
> > this no-one informed
> > J> me.
> >
> > Switching from if_start to if_transmit effectively disables
> > ALTQ support.
> >
> > AFAIR, there is some magic implemented in other drivers that
> > makes them
> > modern (that means using if_transmit), but still capable to
> > switch to queueing
> > mode if SIOCADDALTQ was casted upon them.
> >
>
> It seems pretty difficult to say that something is compatible with
> something else if it hasn't been tested in a few years.
>
> It seems to me that ATLQ is the one that should handle if_transmit.
> although it's a good argument for having a raw "send" function in
> drivers. Ethernet drivers don't need more than a send() routing that
> loads a packet into the ring. The decision on what to do if you can't
> queue a packet should be in the  network layer, if we must still call
> things layers.
>
> "start" is a leftover from a day when you stuffed a buffer and waited
> for an interrupt to stuff in another. The whole idea is antiquated.
>
> Imagine drivers that pull packets off of a card and simply queue it;
> and that you simply submit a packet to be queued for transmit. Instead
> of trying to find 35 programmers that understand all of the lock BS,
> you only need to have a couple.
>
> I always disable all of the gobbledegook like checksum offloading. They
> just muddy the water and have very little effect on performance. A modern
> cpu can do a checksum as fast as you can manage the "capabilities" without
> disrupting the processing path.
>
> With FreeBSD, every driver is an experience. Some suck so bad that they
> should come with a warning. The MSK driver is completely useless, as
> an example.
>
>
> BC
> ___
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
>

During implementation of if_transmit altq was not considered at all.
The default if_transmit provides some compatibility but that is void since
altq has not been converted to call if_transmit after processing the mbuf.

ALTQ can be adapted quite easily to if_transmit model it just wasn't done
at the time.
With if_transmit model it can even be modularized and not be a compile
kernel option since the queue of the iface is abstracted now.

I have always wanted to do a diff but have not yet got to it.
The change is quite simple just provide an altq_transmit default method and
just hook into if_transmit model on the fly.
You surely need to handle some iface events and enable altq based on
request but its is not a hard to implement.

I will always have this in my TODO but not sure when i can get to it.

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

Re: igb and ALTQ in 9.1-rc3

[Barney Cordoba]

--- On Tue, 12/11/12, Gleb Smirnoff  wrote:

> From: Gleb Smirnoff 
> Subject: Re: igb and ALTQ in 9.1-rc3
> To: "Jack Vogel" 
> Cc: "Clement Hermann (nodens)" , "Barney Cordoba" 
> , freebsd-net@FreeBSD.org
> Date: Tuesday, December 11, 2012, 2:58 AM
> On Mon, Dec 10, 2012 at 03:31:19PM
> -0800, Jack Vogel wrote:
> J> UH, maybe asking the owner of the driver would help
> :)
> J> 
> J> ... and no, I've never been aware of doing anything to
> stop supporting altq
> J> so you wouldn't see any commits. If there's something
> in the altq code or
> J> support (which I have nothing to do with) that caused
> this no-one informed
> J> me.
> 
> Switching from if_start to if_transmit effectively disables
> ALTQ support.
> 
> AFAIR, there is some magic implemented in other drivers that
> makes them
> modern (that means using if_transmit), but still capable to
> switch to queueing
> mode if SIOCADDALTQ was casted upon them.
> 

It seems pretty difficult to say that something is compatible with
something else if it hasn't been tested in a few years.

It seems to me that ATLQ is the one that should handle if_transmit. 
although it's a good argument for having a raw "send" function in 
drivers. Ethernet drivers don't need more than a send() routing that
loads a packet into the ring. The decision on what to do if you can't 
queue a packet should be in the  network layer, if we must still call
things layers. 

"start" is a leftover from a day when you stuffed a buffer and waited
for an interrupt to stuff in another. The whole idea is antiquated.

Imagine drivers that pull packets off of a card and simply queue it;
and that you simply submit a packet to be queued for transmit. Instead
of trying to find 35 programmers that understand all of the lock BS,
you only need to have a couple.

I always disable all of the gobbledegook like checksum offloading. They
just muddy the water and have very little effect on performance. A modern
cpu can do a checksum as fast as you can manage the "capabilities" without
disrupting the processing path. 

With FreeBSD, every driver is an experience. Some suck so bad that they
should come with a warning. The MSK driver is completely useless, as
an example.


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

Re: igb and ALTQ in 9.1-rc3

[Jack Vogel]

On Mon, Dec 10, 2012 at 11:58 PM, Gleb Smirnoff  wrote:

> On Mon, Dec 10, 2012 at 03:31:19PM -0800, Jack Vogel wrote:
> J> UH, maybe asking the owner of the driver would help :)
> J>
> J> ... and no, I've never been aware of doing anything to stop supporting
> altq
> J> so you wouldn't see any commits. If there's something in the altq code
> or
> J> support (which I have nothing to do with) that caused this no-one
> informed
> J> me.
>
> Switching from if_start to if_transmit effectively disables ALTQ support.
>
> AFAIR, there is some magic implemented in other drivers that makes them
> modern (that means using if_transmit), but still capable to switch to
> queueing
> mode if SIOCADDALTQ was casted upon them.
>
>
Oh, hmmm, I'll look into the matter after my vacation.

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

Re: igb and ALTQ in 9.1-rc3

[Gleb Smirnoff]

On Mon, Dec 10, 2012 at 03:31:19PM -0800, Jack Vogel wrote:
J> UH, maybe asking the owner of the driver would help :)
J> 
J> ... and no, I've never been aware of doing anything to stop supporting altq
J> so you wouldn't see any commits. If there's something in the altq code or
J> support (which I have nothing to do with) that caused this no-one informed
J> me.

Switching from if_start to if_transmit effectively disables ALTQ support.

AFAIR, there is some magic implemented in other drivers that makes them
modern (that means using if_transmit), but still capable to switch to queueing
mode if SIOCADDALTQ was casted upon them.

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

Re: igb and ALTQ in 9.1-rc3

[Clement Hermann (nodens)]

Le 11/12/2012 00:31, Jack Vogel a écrit :
> UH, maybe asking the owner of the driver would help :)

Indeed. I just assumed anyone on the mailing list would be more
knowledgeable than I am. Sorry about that.

>
> ... and no, I've never been aware of doing anything to stop supporting
> altq
> so you wouldn't see any commits. If there's something in the altq code or
> support (which I have nothing to do with) that caused this no-one informed
> me.
>

Well, that good news (sort of), so there is a bug somewhere (or we
misconfigured something, but we triple-checked, so that is possible but
unlikely). How can we help ?

It does work with the em driver on another card.

I'm not at work today, but I can ask someone to gather information and
send them to the list.

Thanks again.

-- 
Clement Hermann (nodens)
- "L'air pur ? c'est pas en RL, ça ? c'est pas hors charte ?"
Jean in L'Histoire des Pingouins, http://tnemeth.free.fr/fmbl/linuxsf/

Vous trouverez ma clef publique sur le serveur public pgp.mit.edu.
Please find my public key on the public keyserver pgp.mit.edu.

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

Re: igb and ALTQ in 9.1-rc3

[Jack Vogel]

UH, maybe asking the owner of the driver would help :)

... and no, I've never been aware of doing anything to stop supporting altq
so you wouldn't see any commits. If there's something in the altq code or
support (which I have nothing to do with) that caused this no-one informed
me.

Jack


On Mon, Dec 10, 2012 at 2:42 PM, Clement Hermann (nodens) <
nodens2...@gmail.com> wrote:

> Le 10/12/2012 23:09, Barney Cordoba a écrit :
> >
> > --- On Mon, 12/10/12, Clément Hermann (nodens) 
> wrote:
> >
> >> altq(4) states that igb is supported. There are some
> >> references to altq in
> >> if_igb.c (include opt_altq in an ifdef), but they are not in
> >> the em driver
> >> (though my ruleset load fine with a em card).
> >>
> >> Could anyone tell me if igb is supposed to support altq or
> >> not ?
> >>
> >> Thanks,
> >>
> >> Clément (nodens)
> > I'll take a guess that the ALTQ description was written before igb
> > stopped supporting it.
> >
>
> Well, that is a plausible explanation. I thought it might be something
> like that, but since I didn't find any changelog or commit saying
> "dropping support for altq on igb" I was hoping to be wrong.
>
> So you're positive igb does not support altq anymore ?
>
>
> --
> Clement Hermann (nodens)
> - "L'air pur ? c'est pas en RL, ça ? c'est pas hors charte ?"
> Jean in L'Histoire des Pingouins, http://tnemeth.free.fr/fmbl/linuxsf/
>
> Vous trouverez ma clef publique sur le serveur public pgp.mit.edu.
> Please find my public key on the public keyserver pgp.mit.edu.
>
> ___
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
>
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: igb and ALTQ in 9.1-rc3

[Clement Hermann (nodens)]

Le 10/12/2012 23:09, Barney Cordoba a écrit :
>
> --- On Mon, 12/10/12, Clément Hermann (nodens)  wrote:
>
>> altq(4) states that igb is supported. There are some
>> references to altq in
>> if_igb.c (include opt_altq in an ifdef), but they are not in
>> the em driver
>> (though my ruleset load fine with a em card).
>>
>> Could anyone tell me if igb is supposed to support altq or
>> not ?
>>
>> Thanks,
>>
>> Clément (nodens)
> I'll take a guess that the ALTQ description was written before igb
> stopped supporting it.
>

Well, that is a plausible explanation. I thought it might be something
like that, but since I didn't find any changelog or commit saying
"dropping support for altq on igb" I was hoping to be wrong.

So you're positive igb does not support altq anymore ?


-- 
Clement Hermann (nodens)
- "L'air pur ? c'est pas en RL, ça ? c'est pas hors charte ?"
Jean in L'Histoire des Pingouins, http://tnemeth.free.fr/fmbl/linuxsf/

Vous trouverez ma clef publique sur le serveur public pgp.mit.edu.
Please find my public key on the public keyserver pgp.mit.edu.

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

Re: igb and ALTQ in 9.1-rc3

[Barney Cordoba]

--- On Mon, 12/10/12, Clément Hermann (nodens)  wrote:

> From: Clément Hermann (nodens) 
> Subject: igb and ALTQ in 9.1-rc3
> To: freebsd-net@freebsd.org
> Date: Monday, December 10, 2012, 6:03 AM
> Hi there,
> 
> I'm trying to install a new pf/altq router. I needed to use
> 9.1-rc3 due to
> RAID driver issues.
> 
> Everything works find on my quad port intel card (igb), but
> when I try to
> load my ruleset I get the following error :
> 
> pfctl: igb0 : driver does not support ALTQ
> 
> altq(4) states that igb is supported. There are some
> references to altq in
> if_igb.c (include opt_altq in an ifdef), but they are not in
> the em driver
> (though my ruleset load fine with a em card).
> 
> Could anyone tell me if igb is supposed to support altq or
> not ?
> 
> Thanks,
> 
> Clément (nodens)

I'll take a guess that the ALTQ description was written before igb
stopped supporting it.

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