Making MPSAFE/Converting Wi-Fi driver (GSoC)

[Jeandre Kruger]

Hello,

If it it's not much too late to apply for Google Summer of Code
(please tell me if it is), I'm considering either of these, about
which I have a few questions:

https://wiki.netbsd.org/projects/project/mpsafe_net_driver/
https://wiki.netbsd.org/projects/project/Convert_a_Wi-Fi_driver_to_the_new_Wi-Fi_stack/

The latter mentions "fine-grained locking," so is there some overlap
between them? Is the second project much harder than the first? Will
it eventually make the first one redundant?

Is a basic idea of how to use mutexes sufficient, or do you need
experience in writing SMP code, avoiding/debugging race conditions,
etc.? Is a "faster performing card" necessary? Is a true
multiprocessor system necessary or will a netbook with hyper threading
(a single-core Intel Atom processor, but two logical cores) suffice?

I had a quick look at athn.c and it doesn't look too difficult to
follow, although I have no experience working on network drivers. I
have dipped my toes into some bare-metal programming, e.g. x86
assembly, a tiny bit of VGA graphics. Would this be suitable for me,
or should I try to pick another project?

Thanks in advance,
Jeandre

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Martin Husemann]

Post by Jeandre Kruger
Hello,
If it it's not much too late to apply for Google Summer of Code
(please tell me if it is),

It is not, deadline is April 19:
https://developers.google.com/open-source/gsoc/timeline

Post by Jeandre Kruger
I'm considering either of these, about
https://wiki.netbsd.org/projects/project/mpsafe_net_driver/
https://wiki.netbsd.org/projects/project/Convert_a_Wi-Fi_driver_to_the_new_Wi-Fi_stack/
The latter mentions "fine-grained locking," so is there some overlap
between them? Is the second project much harder than the first? Will
it eventually make the first one redundant?

The projects are related, but there are lots of non-wifi network drivers ;-)
So it is maybe easier to read the first project as "make a ethernet
network driver MPSAFE" (we have few examples in tree that already
are, like wm(4)), while the second is specifically about wlan drivers,
where we (additionally to the MPSAFE-ness) are converting to a different
IEEE 802.11 stack, so more than MPSAFE-changes are needed, see:

https://wiki.netbsd.org/Converting_drivers_to_the_new_wifi_stack/

I don't think one of the projects is harder than the other.

Post by Jeandre Kruger
Is a basic idea of how to use mutexes sufficient, or do you need
experience in writing SMP code, avoiding/debugging race conditions,
etc.? Is a "faster performing card" necessary? Is a true
multiprocessor system necessary or will a netbook with hyper threading
(a single-core Intel Atom processor, but two logical cores) suffice?

You need hardware for the driver you are changing - nothing else is
a requirement.

Post by Jeandre Kruger
I had a quick look at athn.c and it doesn't look too difficult to
follow, although I have no experience working on network drivers. I
have dipped my toes into some bare-metal programming, e.g. x86
assembly, a tiny bit of VGA graphics. Would this be suitable for me,
or should I try to pick another project?

I'd say both projects are good for you - just pick what you prefer to
work on.

Martin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Martin Husemann]

Post by Jeandre Kruger
If possible, then, I'd like to apply to convert the athn(4) driver. Then
if time allows I could also do the ath driver (if that makes sense -- both
work with my wifi adapter), the alc Ethernet driver, and/or the bge Ethernet
driver?

The work to be done is very different for ethernet and wifi drivers,
so I would not mix both in one proposal. You could offer two proposals,
one for bge(4) and [if time permits] alc(4), the other for athn(4) and
[if time permits] ath(4).

Martin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Martin Husemann]

Taking that suggestion, here are my draft proposals. I'll appreciate
any feedback. (I put the Ethernet drivers the other way around,
because alc(4) will be easier hardware-wise, but either way should be
possible.)

Both proposals look sane to me. I had suggested the other order of the
ehternet drivers exactly because bge(4) is the way more complex hardware,
but in the end it does not make a big difference for the changes you would
need to make (I guess, not being familiar with either).

For athn there is the additional complexity of the usb variant - if you
can not test pci/cardbus but only usb (or vice versa) you should state
that explicitly [modify the goal accordingly]. There is no real difference
(from the drivers point of view) between cardbus and pci, but usb needs
slightly different handling.

Martin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jeandre Kruger]

Post by Martin Husemann
Both proposals look sane to me. I had suggested the other order of the
ehternet drivers exactly because bge(4) is the way more complex hardware,
but in the end it does not make a big difference for the changes you would
need to make (I guess, not being familiar with either).

I've submitted the wifi proposal. As for the ethernet one, doing
bge(4) first should be possible, but I'd need to get a replacement
part for the computer that has a Broadcom controller (delivery will
take ~3 weeks) and still can't guarantee for certain that it would
work.

I think it would most likely be fine, but after making that clearer in
the proposal, I wonder how practical a proposal with that kind of
variable is, if it turns out that alc(4) alone isn't enough work.

Post by Martin Husemann
For athn there is the additional complexity of the usb variant - if you
can not test pci/cardbus but only usb (or vice versa) you should state
that explicitly [modify the goal accordingly]. There is no real difference
(from the drivers point of view) between cardbus and pci, but usb needs
slightly different handling.

OK.

Kind regards, Jeandre

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Martin Husemann]

Post by Jeandre Kruger
I've submitted the wifi proposal. As for the ethernet one, doing
bge(4) first should be possible, but I'd need to get a replacement
part for the computer that has a Broadcom controller (delivery will
take ~3 weeks) and still can't guarantee for certain that it would
work.

OK, no big deal - order is not that important overall. Add a note that
you could try the optional second conversion for bge(4) if your hardware
is working at that point (and of course not, if it isn't).

Martin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jeandre Kruger]

Sorry, neglected to CC mailing list...

On Sat, Apr 16, 2022 at 11:39 PM Jeandre Kruger

Post by Martin Husemann
The work to be done is very different for ethernet and wifi drivers,
so I would not mix both in one proposal. You could offer two proposals,
one for bge(4) and [if time permits] alc(4), the other for athn(4) and
[if time permits] ath(4).

Taking that suggestion, here are my draft proposals. I'll appreciate
any feedback. (I put the Ethernet drivers the other way around,
because alc(4) will be easier hardware-wise, but either way should be
possible.)
Update Atheros Wi-Fi driver(s) for new Wi-Fi stack
SUMMARY
The NetBSD Project has been working to adapt the FreeBSD Wi-Fi stack.
When this is complete, things will be more up-to-date, and NetBSD will
let one use multiple Virtual Access Points with the same Wi-Fi
adapter. As of yet, most of the Wi-Fi drivers need to be converted to
the new stack. The athn(4) driver will be reworked as necessary, and
if time permits the ath(4) driver also.
DELIVERABLES
When complete, these devices will be usable on the "wifi" Mercurial
topic with the new stack.
IMPLEMENTATION
This should be straightforward. Among other things the driver will
need to be changed to use fine-grained locking instead of the big
kernel lock. The existing converted drivers can serve for reference.
My netbook has an Atheros 9285 Wi-Fi adapter. The default (preferred)
driver is athn(4), but it also works with the ath(4) driver, which
supports a somewhat different set of Wi-Fi adapters.
http://mail-index.netbsd.org/tech-net/2022/04/13/msg008184.html
SCHEDULE
May 20-June 12 (UTC)
Familiarize self with driver, necessary interfaces, & differences in
https://wiki.netbsd.org/Testing_new_wifi/
https://wiki.netbsd.org/Converting_drivers_to_the_new_wifi_stack/
Begin coding a bit – dev/pci/if_athn_pci.c and dev/ic/athn.c
Ascertain any possible problems, or necessary tasks not here
mentioned, with help of mentor.
June 13-June 27
Official start of coding. At least the most trivial changes of those
outlined in wiki article should be made in athn(4).
June 27-September 12
Finish reworking and testing athn(4) as necessary.
If athn(4) is completed soon enough, update the ath(4) driver analogously.
September 12 End of coding
Make Ethernet drivers MPSAFE: alc(4), possibly bge(4)
SUMMARY
The NetBSD network stack presently requires the big kernel lock to be
held, limiting performance with multiple processor cores. The alc(4)
driver, for a range of Atheros Ethernet interfaces, will be reworked
so as not to need the protection of the big kernel lock; and if
possible and time permits, the bge(4) driver also, for Broadcom
Gigabit interfaces.
DELIVERABLES
When completed the drivers will allow for greater performance with
networking on SMP systems (provided the NET_MPSAFE kernel option is
enabled). Such Atheros Ethernet interfaces appear to be common, so
hopefully this will be of some benefit to many NetBSD users.
(Implementation as detailed in schedule. I have access to more than
one device with an Atheros Ethernet adapter, and a computer which
shouldn't be hard to fix with a Broadcom Gigabit integrated
controller.)
SCHEDULE
May 20-June 12 (UTC)
Familiarize self with structure of alc(4) driver, Ethernet, and
relevant NetBSD interfaces, as necessary. Study doc/TODO.smpnet and
dev/pci/if_alc.c.
Use existing MPSAFE drivers for reference. Determine what needs to be
protected by mutexes.
June 13-September 12
Rework and test alc(4) as much as necessary. If alc(4) is completed
soon enough, begin work on bge(4) and convert it analogously.
BIOGRAPHY
Since beginning programming with Scratch at age 7 in 2011, I've gained
some practice with various programming languages, including C and x86
assembly. I've written some small personal projects – if I don't just
abandon them, they aren't usually very practical, but I learn
something nevertheless.
Trying out ancient UNIX and VAX BSDs on SimH was fun, although now it
has been shown that ancient UNIX probably can't be redistributed
outside the US. I've found operating systems fascinating for most of
my life – since before I began programming – and would be enthusiastic
to help improve one.
https://ldjam.com/events/ludum-dare/40/pet-overload
The most recent thing I've programmed is a basic RISC-V M-mode
emulator in Scratch – not capable of running NetBSD or any operating
system, but it runs several small C and assembly programs, including a
https://github.com/Jonathan50/scratch-risc-v-programs
Contact: Email or on #netbsd-code

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jeandre Kruger]

Post by Martin Husemann
https://developers.google.com/open-source/gsoc/timeline

Thanks, I was a bit vague -- I'm aware of the deadline but I was wondering if
I hadn't done enough preparation in advance.

Post by Martin Husemann
The projects are related, but there are lots of non-wifi network drivers ;-)
So it is maybe easier to read the first project as "make a ethernet
network driver MPSAFE" (we have few examples in tree that already
are, like wm(4)), while the second is specifically about wlan drivers,
where we (additionally to the MPSAFE-ness) are converting to a different
https://wiki.netbsd.org/Converting_drivers_to_the_new_wifi_stack/
I don't think one of the projects is harder than the other.
You need hardware for the driver you are changing - nothing else is
a requirement.
I'd say both projects are good for you - just pick what you prefer to
work on.
Martin

OK, that helps a lot. I would've worried a bit about bugs that would
be apparent only on higher-performing hardware, but maybe I'm
overestimating the complexity.

If possible, then, I'd like to apply to convert the athn(4) driver. Then
if time allows I could also do the ath driver (if that makes sense -- both
work with my wifi adapter), the alc Ethernet driver, and/or the bge Ethernet
driver?

Kind regards, Jeandre

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de