Message-ID: <CAK8U23bj0jqA5KNPN8oZxxf5gN7M2Acp3_qpeDz+uxk6kbmRUA@mail.gmail.com>
Date: Mon, 9 Jun 2025 07:35:59 -0300
From: Ramon Fontes <ramonreisfontes@...il.com>
To: Alexander Aring <aahringo@...hat.com>
Cc: davem@...emloft.net, kuba@...nel.org, pabeni@...hat.com, 
	linux-wpan@...r.kernel.org, alex.aring@...il.com, miquel.raynal@...tlin.com, 
	netdev@...r.kernel.org
Subject: Re: [PATCH] Integration with the user space

> That's why there exist addresses.

The addresses are really important here. However, that still requires
the entire emulation logic, including per-link delay, loss, and
interference modeling to be implemented and managed manually in user
space. The approach proposed here aims to offload this complexity by
providing an integrated solution at the PHY level, before packets
reach the MAC, where interference and delivery decisions can be made
consistently and transparently, without requiring user space to
replicate the entire logic. In that sense, while addresses do help
identify the destination, they are not sufficient alone to handle the
broader scope of realistic wireless emulation, especially when
topology-aware behavior and MAC feedback are needed.

> Teach netem to deal with addresses on a generic filter hook.
> Maybe you can ask at batman project how they test things because they
> use 80211 mesh functionality?

I'm familiar with the BATMAN project, as well as IEEE 802.11s, OLSR,
Babel, and other mesh routing protocols. In fact, I authored a book
chapter in 2022 specifically on these protocols, focusing on their use
in wireless networking. That work was centered on wireless network
emulation, where I provided practical examples of how to deploy and
test these protocols in Linux-based environments.

That said, all the netem-based approaches, while useful, are not
sufficient on their own to address the broader requirements of
realistic wireless emulation. They lack integration with physical
layer behavior, cannot model per-link dynamics based on distance or
interference, and offer limited support for topological asymmetry and
MAC-level feedback, which are essential for accurate and reproducible
wireless testing.

Book chapter ref: https://digital-library.theiet.org/doi/10.1049/pbte101e_ch1

> I looked more closely at the patches and there are a lot of question
> marks coming up, for example why there is virtio handling, when this
> patch should not do anything with virtio?

I agree with you. That's actually something I had been thinking about
as well. I believe we can remove the virtio-related handling for now,
as it doesn’t belong in the scope of this patch. If needed, we can
revisit it separately in a follow-up patch that properly addresses its
purpose.

> Why do we introduce a second data structure to keep registered hwsim phys?

The second data structure, in this case, (the rhashtable?), was
introduced to allow efficient lookup and management of registered
hwsim PHYs based on attributes such as the portid or virtual address.

The existing hwsim_phys list is sufficient for basic iteration over
all PHYs, but it becomes inefficient and cumbersome when we need:

- Fast lookup by a unique identifier (e.g., portid, ieee_addr);
- To support operations like remove_user_radios() efficiently;
- To associate radios with specific users or namespaces (net),
particularly when cleaning up after NETLINK_URELEASE or network
namespace shutdown.

Additionally, this follows the same architectural pattern used in
mac80211_hwsim, where similar per-radio or per-user management is
needed.

So the rhashtable is not a replacement but a complementary structure
optimized for use cases that require fast indexed access or
conditional cleanup, while the existing list remains useful for
ordered traversal and general-purpose iteration.

Honestly, I chose to keep the existing structure to ensure I wasn’t
changing the current behavior of mac802154_hwsim. The intention was to
maintain compatibility and avoid introducing any regressions, while
extending the functionality in a non-intrusive way.

> Why do we have a lot of wording of "wmediumd" when this is the
> project/process part in user space?

I should probably reconsider the title of the PR, especially since
mac802154_hwsim already supports user-space interaction independently.

As for the use of the term "wmediumd", I chose to reuse it because the
new functionality aligns closely with the goals and structure of the
original wmediumd project for mac80211_hwsim. Since both
mac80211_hwsim and mac802154_hwsim serve a similar purpose, enabling
kernel-level virtual radios for wireless experimentation, it felt
natural to extend the naming convention to indicate compatibility and
continuity. I didn’t see the need to reinvent something new when the
existing model worked well and was familiar to the community.

--
Ramon
Em dom., 8 de jun. de 2025 às 22:49, Alexander Aring
<aahringo@...hat.com> escreveu:
>
> Hi,
>
> On Sat, Jun 7, 2025 at 5:00 PM Ramon Fontes <ramonreisfontes@...il.com> wrote:
> >
> > > There is a generic way by using netem qdisc and using AF_PACKET
> > without PACKET_QDISC_BYPASS, should do something like that.
> > If you really want to do something else there or only act on 802.15.4
> > fields and you hit the limitations of netem then this is something
> > netem needs to be extended.
> >
> > Let’s say I’m quite familiar with netem - netem is indeed well-known
> > and has been used extensively with tc/ifb. However, it is primarily
> > suited for 1-to-1 communication scenarios.
> > In 1-to-n topologies, such as when node 0 communicates with both node
> > 1 and node 2, it becomes unclear which peer should serve as the
> > reference for applying delay, loss, or latency.
>
> That's why there exist addresses.
>
> > This limitation makes netem unsuitable for scenarios where
> > link-specific behavior is required, such as in ad hoc networks.
> > In such cases, a more precise per-link control - as provided by
> > wmediumd - becomes necessary.
> >
>
> Teach netem to deal with addresses on a generic filter hook.
> Maybe you can ask at batman project how they test things because they
> use 80211 mesh functionality?
>
> > > With that being said, however there are so few users of 802.15.4 in
> > Linux and adding your specific stuff, I might add it if this helps you
> > currently... but I think there are better ways to accomplish your use
> > cases by using existing generic infrastructure and don't add handling
> > for that into hwsim.
> >
> > Back in 2016, mac80211_hwsim had relatively few users. Today, I
> > maintain a community of approximately 1,000 users worldwide who rely
> > on mac80211_hwsim for their research - industry and academy.
> > The need for a realistic experimental platform is not a personal
> > requirement, but rather a broader gap in the ecosystem. Addressing
> > this gap has the potential to significantly advance research on IEEE
> > 802.15.4.
> >
> > > but I think there are better ways to accomplish your use
> > cases by using existing generic infrastructure and don't add handling
> > for that into hwsim.
> >
> > Honestly, based on my experience so far, there’s no better approach
> > available. Well - there is one: integrating all the wmediumd
> > functionality directly into the kernel module itself. But I fully
> > agree - that would be both unrealistic and impractical.
> >
>
> I looked more closely at the patches and there are a lot of question
> marks coming up, for example why there is virtio handling, when this
> patch should not do anything with virtio?
> Why do we introduce a second data structure to keep registered hwsim phys?
> Why do we have a lot of wording of "wmediumd" when this is the
> project/process part in user space?
>
> - Alex
>

Powered by blists - more mailing lists