Question on sysctl tree handling
Matt Joras
matt.joras at gmail.com
Mon Apr 11 22:09:31 UTC 2016
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"
More information about the freebsd-net
mailing list