em(4) + ALTQ broken

[Jack Vogel]

Just teseted, and at least in the kernel build I'm doing its definitely
defining
that code on, hit my syntax error rebuilding em.

Jack


On Tue, Feb 2, 2010 at 2:43 PM, Jack Vogel <jfvogel at gmail.com> wrote:

> It should never get to the drbr code, look at net/if_var.h, in the inline
> definition
> of drbr_dequeue() there is an #ifdef ALTQ that will effectively vector if
> to use
> the old IFQ_DRV_DEQUEUE() method.
>
> I guess I can test the build on a system here, stick some syntax error in
> and see if it hits.
>
> Right now the inserted code looks solid enough to me, so somehow I think
> its not being defined.
>
> Jack
>
>
>
> On Tue, Feb 2, 2010 at 2:38 PM, Pyun YongHyeon <pyunyh at gmail.com> wrote:
>
>> On Tue, Feb 02, 2010 at 01:41:01PM -0800, Jack Vogel wrote:
>> > LOL, and I can answer my own question, I just looked and the ONLY
>> > 1Gig drivers using multiqueue are mine, so I guess not eh? :)
>> >
>>
>> I was wrong. ALTQ is defined in opt_global.h so drbr_ interface
>> should already see ALTQ. I have to look into drbr_ code.
>>
>> > J.
>> >
>> > On Tue, Feb 2, 2010 at 1:39 PM, Jack Vogel <jfvogel at gmail.com> wrote:
>> >
>> > > Thanks Max, yes, i've done some digging myself and now see how things
>> > > work, the rubber meets the road in the defines in if_var.h.
>> > >
>> > > And what it does is effectively short circuit Kip Macy's multiqueue
>> code
>> > > in favor of the old method.
>> > >
>> > > Right now I can see two possibilities, either the defines are not set
>> in
>> > > the build, OR there is something wrong in the logic of the short
>> circuit
>> > > approach in Kip's code.
>> > >
>> > > A question might be if ANY driver that is usinig TX Multiqueue has
>> been
>> > > successfully used with ALTQ?
>> > >
>> > > Jack
>> > >
>> > >
>> > >
>> > > On Tue, Feb 2, 2010 at 12:37 PM, Max Laier <max at love2party.net>
>> wrote:
>> > >
>> > >> On Tuesday 02 February 2010 18:48:02 Jack Vogel wrote:
>> > >> > So apparently this thing needs no special knowledge in the driver,
>> yet
>> > >> > something in
>> > >> > the new code breaks it, can someone explain tersely how the altq
>> app
>> > >> > actually
>> > >> > "pokes" or "hooks up" to the driver? I am not clear about that and
>> I
>> > >> >  suspect if I was
>> > >> > this would all be clearer.
>> > >>
>> > >> The whole story is in
>> > >>
>> > >>  man 9 altq
>> > >>
>> > >> long story short, as long as you consistently use the IFQ_* macros to
>> > >> manage
>> > >> the interface queue, things should just work.  if_var.h used to
>> > >> conditionally
>> > >> define these macros to avoid ALTQ overhead when the kernel is built
>> > >> without
>> > >> ALTQ.  This has changed a long time ago and should not make any
>> difference
>> > >> anymore.
>> > >>
>> > >> I can't figure out who the OP is, but could you make sure that the
>> > >> includes
>> > >> that are used to built the kernel are up to date?  You are building
>> with
>> > >> the
>> > >> buildkernel target and not "the old way", right?  Also, if you build
>> just
>> > >> the
>> > >> module, the build might pick up the includes from /usr/include
>> instead of
>> > >> src/sys ...
>> > >>
>> > >> > Jack
>> > >> >
>> > >> > On Tue, Feb 2, 2010 at 9:37 AM, Pyun YongHyeon <pyunyh at gmail.com>
>> > >> wrote:
>> > >> > > On Tue, Feb 02, 2010 at 09:30:52AM -0800, Nick Rogers wrote:
>> > >> > > > > I guess the problem comes from multi-queue support. The drbr
>> > >> > > > > interface is implemented with inline function so em(4)/igb(4)
>> may
>> > >> > > > > have to define ALTQ to the header. I have not tested the
>> patch(no
>> > >> > > > > time at this moment) but would you give it try?
>> > >> > > > >
>> > >> > > > > I tried the patch and it did not work.
>> > >> > >
>> > >> > > You rebuilt kernel, right? Rebuilding kernel module has no
>> effect.
>> > >> >
>> > >> > _______________________________________________
>> > >> > freebsd-stable at freebsd.org mailing list
>> > >> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> > >> > To unsubscribe, send any mail to "
>> > >> freebsd-stable-unsubscribe at freebsd.org"
>> > >> >
>> > >> >
>> > >> > !DSPAM:4b686584144321871135632!
>> > >> >
>> > >>
>> > >
>> > >
>>
>
>