Question on sysctl tree handling

[Jack Vogel]

Hmmm,  after so many years of unloading and reloading drivers, it just
seemed like such
a convenience :)  But, instability isn't fun either, I've looked at bxe a
little, such a monstrous
driver :)

I'll give it some thought, and maybe discuss it with David. Thanks.

Cheers,

Jack


On Mon, Apr 11, 2016 at 3:09 PM, Matt Joras <matt.joras at gmail.com> wrote:

> Expanding on what mmacy said... I don't think the benefits of "easy
> reconfiguration" are worth the headaches you're going to potentially
> run into in production.
>
> bxe(4) used to do this, and it caused us a lot of problems (i.e. panics)
> at $DAY_JOB. For example, if a lagg was on top of bxe and then you
> downed bxe you could very easily hit a use-after-free since bxe free'd
> its rings while if_lagg is trying to transmit a packet.
>
> Matt Joras
>
> On Mon, Apr 11, 2016 at 2:03 PM, K. Macy <kmacy at freebsd.org> wrote:
> > You do understand that init needs to be run every time interface
> > settings are changed (TSO / PROMISC / CSUM/ etc)? Reallocating queues
> > and interrupts every time is fragile (long running systems can run low
> > on contiguous memory) and, in the common case that you're not actually
> > changing the number, gratuitous.
> >
> > Cheers.
> > -M
> >
> > On Fri, Apr 8, 2016 at 2:56 PM, Jack Vogel <jfvogel at gmail.com> wrote:
> >> LOL, why does it seem that as soon as I ask the answer hits me in the
> nose
> >> :)
> >>
> >> I found the sysctl_ctx_free call, sorry for the noise....
> >>
> >> Jack
> >>
> >>
> >> On Fri, Apr 8, 2016 at 2:51 PM, Jack Vogel <jfvogel at gmail.com> wrote:
> >>
> >>>
> >>> I have a driver design where the queue/ring/irq layout is done in init
> >>> rather
> >>> than in attach, allowing easy reconfiguration. What I'm not sure about
> is
> >>> how to handle the sysctl tree during a reinit, I don't see a procedure
> to
> >>> free up things so I can restructure :(
> >>>
> >>> Am I missing something, any pointers or suggestions appreciated.
> >>>
> >>> Thanks,
> >>>
> >>> Jack
> >>>
> >>>
> >> _______________________________________________
> >> freebsd-net at freebsd.org mailing list
> >> https://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
> > https://lists.freebsd.org/mailman/listinfo/freebsd-net
> > To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>