igb and ALTQ in 9.1-rc3

[Nick Rogers]

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.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
>>>>>
>>>>> 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 at freebsd.org mailing list
>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>>
>> _______________________________________________
>> freebsd-net at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>
>
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"