[CC'ing more people for a wider discussion]
On Sat, 2008-12-06 at 07:26 -0800, Igor Trindade Oliveira wrote:
> i was seeing your description about mac80211 hwsim in kernelnewbies
> and i see something about mac80211 userspace API.
> you can explain your idea?
I think the userspace API idea is probably not a good idea as is, it
makes it very complicated to program things, I guess hwsim should be
extended instead.
One thing I was especially looking for is, instead of having "virtual
air" inside the kernel, have "virtual air" in userspace.
For example, consider this scenario with three mesh points:
MP1 ---- MP2 ---- MP3
where MP1 and MP3 cannot directly communicate because they are too far
apart, physically. It isn't possible to test such a scenario with hwsim
because hwsim has no concept of distance.
One easy solution to this would be to introduce "air groups", each just
a number. In mac80211_hwsim_tx_frame, we have:
list_for_each_entry(data2, &hwsim_radios, list) {
struct sk_buff *nskb;
if (data == data2)
continue;
if (!data2->started || !data2->radio_enabled ||
!hwsim_ps_rx_ok(data2, skb) ||
data->channel->center_freq != data2->channel->center_freq)
continue;
The easiest way to do "air groups" would be to add:
if (!(data->airgroups & data2->airgroups))
continue;
and have the "airgroups" value be a u32 (or u64?) which can be modified
in configfs and defaults to 1. That way, you can have up to 32 (64)
groups (each bit being a group) and the above picture would become:
virtual device: MP1 ---- MP2 ---- MP3
airgroups: 1 3 2
Does that make sense? Do you think it's flexible enough? Should we maybe
use a u64 so we have more flexibility? It should be fairly easy to do
this, I think.
Of course, this isn't as general as it could be. I suppose some testing
scenarios will require simulating packet loss and similar, so we'll want
to have userspace make the decision about which packets get to which
radios. For this, you'd want to have a radiotap interface per virtual
hardware, which shows all frames transmitted by this virtual hardware
and, when frames are sent into that interface, the frame is given to
mac80211.
That would be the most generic way, but since it's also a lot more
complex I think there still is value in having the "airgroups" above,
especially since if we implement this idea then we still need a way to
decouple the virtual radios from the "virtual air" that's implemented in
the kernel, which perfectly fits with setting all "airgroups" to zero
which makes the "virtual air" in the kernel that I quoted above do
nothing.
Thoughts?
johannes
Johannes,
On Sun, Dec 7, 2008 at 5:57 AM, Johannes Berg <[email protected]> wrote:
> For example, consider this scenario with three mesh points:
>
> MP1 ---- MP2 ---- MP3
>
> where MP1 and MP3 cannot directly communicate because they are too far
> apart, physically. It isn't possible to test such a scenario with hwsim
> because hwsim has no concept of distance.
>
> One easy solution to this would be to introduce "air groups", each just
> a number.
>
> [...]
>
> Does that make sense? Do you think it's flexible enough? Should we maybe
> use a u64 so we have more flexibility? It should be fairly easy to do
> this, I think.
>
>
> Of course, this isn't as general as it could be.
To be useful for our mesh tests this "virtual air" would have to allow
us to create 3 groups, each one a superset of the previous. The
smallest group would be the set of nodes that can a node communicate
with ("A can talk to B"). The next larger group would be nodes on
which a node that can interfere ("A can screw up C's reception").
Finally, the largest would be nodes that can detect each other ("A can
detect when D is transmitting").
Cheers,
Javier
--
Javier Cardona
cozybit Inc.
On Mon, 2008-12-08 at 12:25 -0800, Javier Cardona wrote:
> > That's something we can't actually simulate since you're trying to see
> > whether they do NAV updates correctly, right?
>
> I was trying to simulate hidden nodes, which are unavoidable given the
> distributed nature of the mesh.
> Also trying to simulate "starvation at the edges", which varies
> greatly with the collision avoidance threshold.
> But, hey, I was just day dreaming. Even the simpler air groups that
> you proposed would be very useful.
:)
Makes a lot of sense, and you can maybe even implement that when a
userspace program is doing the packet propagation, but for topology
testing I think we should start with the simpler groups thing. And as I
said, the userspace propagation will actually need to turn off in-kernel
propagation which fits setting airgroups to 0.
johannes
Johannes,
On Mon, Dec 8, 2008 at 11:52 AM, Johannes Berg
<[email protected]> wrote:
> On Mon, 2008-12-08 at 10:17 -0800, Javier Cardona wrote:
>
>> To be useful for our mesh tests this "virtual air" would have to allow
>> us to create 3 groups, each one a superset of the previous. The
>> smallest group would be the set of nodes that can a node communicate
>> with ("A can talk to B"). The next larger group would be nodes on
>> which a node that can interfere ("A can screw up C's reception").
>> Finally, the largest would be nodes that can detect each other ("A can
>> detect when D is transmitting").
>
> That's something we can't actually simulate since you're trying to see
> whether they do NAV updates correctly, right?
I was trying to simulate hidden nodes, which are unavoidable given the
distributed nature of the mesh.
Also trying to simulate "starvation at the edges", which varies
greatly with the collision avoidance threshold.
But, hey, I was just day dreaming. Even the simpler air groups that
you proposed would be very useful.
Thanks!
Javier
--
Javier Cardona
cozybit Inc.
On Mon, 2008-12-08 at 10:17 -0800, Javier Cardona wrote:
> To be useful for our mesh tests this "virtual air" would have to allow
> us to create 3 groups, each one a superset of the previous. The
> smallest group would be the set of nodes that can a node communicate
> with ("A can talk to B"). The next larger group would be nodes on
> which a node that can interfere ("A can screw up C's reception").
> Finally, the largest would be nodes that can detect each other ("A can
> detect when D is transmitting").
That's something we can't actually simulate since you're trying to see
whether they do NAV updates correctly, right?
johannes