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
> <fodillemlinkarim at gmail.com> 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.c?revision=248906&view=markup>
> http://svnweb.freebsd.org/**base/head/sys/dev/e1000/if_**
> igb.h?revision=248908&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 <ncrogers at gmail.com> wrote:
>
>  On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel <jfvogel at gmail.com> wrote:
>
> On Mon, Dec 10, 2012 at 11:58 PM, Gleb Smirnoff <glebius at freebsd.org>
>
> 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
>
>