 Hello everyone, I'm Nwei Wu from National Chang Kong University at Taiwan. Today I'm going to talk about our project, BYFI, which offers lightweight and fast Wi-Fi access in virtual machines. So firstly, let's introduce myself. I'm a new graduate from National Chang Kong University at Taiwan, and previously I was an intern of FreeBSD Foundation for improving wireless device driver. Also, I have contributed to FreeBSD and Linux Mac L211 hardware scene, and my primary interests are in kernel development and wireless networking. So this is why I have been working on BYFI with my teacher Jun Huang and other contributors. So to begin with, we will talk about why do we need lightweight Wi-Fi access. We'll cover some situations that can benefit from having a lightweight Wi-Fi access. Then we'll talk about our project BYFI, which is a lightweight solution for having Wi-Fi access. Then we'll talk about the internal of BYFI, and you might be surprised by how lightweight BYFI is. And then we'll make a short comparison between BYFI and the Mac L211 hardware scene, which is a Wi-Fi simulator in Linux kernel. Let's begin our list. We'll talk about our future work and see how can we make BYFI faster and more lightweight. So first of all, why do we need lightweight Wi-Fi access? There are some situations that we would like to have wireless interfaces without a complex software stack. For example, for continuous integration, we would like to have wireless interfaces without a complex software stack so that it can reduce our cost and time for building environment. Another example is application which needs Wi-Fi connectivity. Traditionally, a setting up a wireless environment is not an easy job because it usually needs a complex software stack as well as wireless hardware. However, with BYFI, we use a more lightweight software stack and we don't need a hardware because BYFI itself can simulate virtual wireless interfaces. And the other example is having a lightweight software stack makes it easier to be deployed into a virtualized environment. We'll show you how easy it is to deploy a Wi-Fi into a virtualized environment. The last thing is to reduce resource usage in virtualized environment. There are some situations that developer wants to test wireless environment with lots of wireless interfaces. In these cases, using a more lightweight software stack usually means fewer resource usage like memory consumption. Actually, there is already a Wi-Fi simulator in Linux kernel which is called Mac L211 tower theme. In the following slides, I will refer it as hardware theme for simplicity. The hardware theme involves a complex software stack. For example, for scanning process, it takes 2,675 function calls in a Wi-Fi stack. On the other hand, VFI only takes 63 function calls for scanning process. This is why VFI is a lightweight solution for having Wi-Fi access. So we have mentioned that why do we need a solution for having a lightweight Wi-Fi access? So it's time to introduce our project VFI. As you have already know, VFI is a lightweight wireless simulator which works with a smaller software stack. Actually, we don't implement all the A02.11 protocol in VFI in order to offer just work wireless interfaces. Some cases we've already mentioned don't need a full pack of A02.11 protocol. In these cases, having a just work wireless interface satisfy our need. The other thing is VFI is easy to be deployed to a virtualized environment which needs only a little modification of VFI. Actually, VFI has two different behaviors depends on whether it is running on a host only or is running on a VM. When running on a host only, VFI is a lightweight alternative of hardware sync. On the other hand, when running VFI on a VM, it becomes a wireless version of a VRTiOnet driver. We'll cover why VFI can provide wireless interfaces while having the VRTiOnet device as its backend device. So let's talk about running on a host only first. When running on a host only, VFI is a lightweight alternative of hardware sync. The figure compares the software stack between hardware sync and VFI. And as you can see, hardware sync works with both CFGL211 and MACGL211. On the other hand, VFI works with only CFGL211. And the software stack VFI works with is nearly the half of the hardware sync. So this is why VFI is more lightweight. And the second behavior of VFI is when running on the VM. When running on a VM, VFI becomes a wireless version of VRTiOnet driver. It means it has the ability to communicate with external entity and fulfill inter-VM communication. And the reason why we call VFI as a wireless version of VRTiOnet driver is because VFI uses VRTiOnet device as our backend device. However, compared with the original VRTiOnet driver, VFI provides wireless interfaces rather than the Ethernet interfaces. So for now, you might be curious about the internal of VFI. So let's talk about it. Basically, VFI is a CFGL211 4MAC driver. It means VFI works with CFGL211 as its Wi-Fi stack. And how does VFI become a CFGL211 driver is by implementing the operations defined by CFGL211 like the figure shows. And whenever a user requests a scan, it ends up calling the VFI scan function which is assigned to the CFGL211 OPS. The same thing happens for the other operations like connect and disconnect. For CFGL211 drivers, CFGL211 delegates the management of AL2.11 protocol to CFGL211 drivers and their firmware. This means most of the AL2.11 protocol is implemented at CFGL211 drivers and their firmware. And normally, a CFGL211 driver and its firmware will implement all the AL2.11 protocol. However, our VFI implements only a small subset of AL2.11 protocol. So this is why VFI is more lightweight in management path. The other feature for CFGL211 drivers is that CFGL211 drivers get Ethernet frames from network device layer. And normally, a CFGL211 driver and its firmware will encapsulate the Ethernet frames into AL2.11 frames. However, our VFI transmits Ethernet frames directly without encapsulating them into AL2.11 frames. And this is the secret why VFI can make use of root ALnet device as our backend device. And this is also why VFI is more lightweight in data path. Let's talk about more detail about data path. As we have already mentioned, VFI gets Ethernet frames from network device layer. And then the behavior is different. It depends on whether VFI is running on the host only or it is running on a VM. When VFI is running on host only, it then sends Ethernet frames into another wireless interface in VFI. If you have ever heard of the VETH in Linux kernel, the behavior here is much the same as like in VETH. That is, a transmission for an interface turns out to be the reception of another interface. However, in our cases of VFI, we're using the wireless interface. The second behavior is that VFI is when VFI is running on the VM, it then sends Ethernet frames into a virtual device via VQ. And this is feasible because virtual net device receives Ethernet frames from its front-end driver. Let's see how data goes when VFI is running on a VM. Here is the diagram that the whole diagram is in a QML process, which means it is a guest machine. First of all, a data application has some data to send. It then calls system call to let kernel handle the data. And the data arrives at system call interface and then circular and then network protocol stack. At this time, the data has been encapsulated in a specific protocol header. In most cases, it's the IP header. And then network protocol layer passes the packet into the net device layer. And the net device layer pushes the Ethernet header in front of the packet and passes into the VFI. And then VFI passes the Ethernet frames to the virtual net device via VQ. So for now, we're at the bottom of the QML process. So let's see where are we at at the viewpoint of the whole system. This is where we're at. We're at the bottom of the QML process, which is virtual net device. And let's see what we have in host kernel space. There are TAP devices and bridge device. And each of the TAP devices is connected with virtual net device in a QML process. Also, each of the TAP devices is measured on bridge device. And with this setting, the two QML processes have been successfully connected. And let's see when the virtual net device passes the Ethernet frames to the TAP device. Then the TAP devices and the bridge device will do L2 forwarding for us so that the Ethernet frames can arrive at the virtual net device in the other QML process. Then the Ethernet frames arrive at the VFI of another QML process. Then you can guess what's going on. The data application in the other QML process finally gets the data from the other data application in the original QML process. So after talking about the data path, let's focus on the management path. CFGL 2.11 invokes the operations within CFGL 2.11 driver to satisfy a user's request. For example, like we have already mentioned, whenever a user requests a scan, it ends up calling the VFI scan, which is assigned to the CFGL 2.11 OPS. And the other thing is most CFGL 2.11 drivers prepare and transmit L2.11 management frames in these functions. However, remember that VFI can only send Ethernet frames because it uses a virtual net device as its backend device. So in this case, VFI needs to prepare and transmit Ethernet frames. So how does VFI do this is by converting the L2.11 management frames into Ethernet frames. For example, this is the structure of L2.11 management frame for scanning requests. And how VFI does this is by keeping the management frame body still. And then turns the L2.11 MAC header into the Ethernet MAC header. And that's all, not really. You can find that we have lost a field for the MAC address. As you can see, there is an extra MAC address field in the L2.11 MAC header. And in most cases, this extra MAC address is to tell what BSS we belong. So with only two MAC addresses in our Ethernet MAC header, we're not able to show the BSS that we belong. Actually, we have come out with some solutions and we choose this solution to keep VFI lightweight. The solution is that each wireless interface maintains a table storing the MAC addresses of all the other interfaces within the same BSS. So whenever a wireless interface receives a frame, it then checks whether the source MAC address is in our table. If it is, it means we're on the same BSS. If not, it means the sender is from the other BSS. So we can drop the frame because the frame is not for us. The other thing I want to mention is that how do we identify whether the frame is a data frame or a management frame? The secret is in the Ethernet MAC header, the PROTO field. For data frames, we store Ether type in the PROTO field like a normal Ethernet frame. On the other hand, for management frames, we store length of the packet in the PROTO field. And the helper function ETH PROTO is AL23 can identify whether the PROTO field is storing the Ether type or it is storing the length of the packet. And the function returns true whenever the PROTO field is storing the Ether type, otherwise it returns false. So identify the frame type is fairly important because we're processing our management frame in VOI file and we don't want our management frame to be passed to the network protocol layer. And here, so we can identify the management, the frame type, so that we can dispatch our frame to whether the data path or the management path. Actually, we have already had some comparison between VOI file and the hardware scene. And so let's talk about other comparison between the two. First of all, VOI file has fewer lines of code than in hardware scene. This is good news because VOI file aims to be a lightweight Wi-Fi simulator. The other example is that VOI file is easy to be deployed into a virtual machine. As you have already know, VOI file makes use of VRTiOnet device and TAP device and also the bridge device. So the only thing to port VOI file into a VM guest is only a small modification of VOI file itself. On the other hand, to port hardware scene to a VM guest is not an easy job because it needs a dedicated VRTiO device for hardware scene as well as some user program which are damaged for hardware scene. Of course, the hardware scene itself needs to be modified so that it can support VRTiO. The last thing is that we use MIT license rather than the GPL license used by MacAO211 hardware scene. So that porting VOI file to other platform is much easier than the hardware scene. Okay, so finally, we can talk about our future work. The first thing is to support multi-Q for VRTiO. So it can reduce the lock contention for containing the VRTQ in VOI file so that it increases the throughput for both transmission and reception. The other thing is to allocate dedicated pages for receive reception buffers so that we don't need to allocate memory each time we receive a frame so that it saves the time to allocate in memory and thus make VOI file faster. And here is our repository and we welcome anyone who is interested in VOI file joining us and any question or feedback will be very precious for us. Thank you, everyone. Hello. Yeah, hi. Have you compared the performance of VOI file with HWSIM? Do you have some numbers? Actually, we have did some comparison but the performance is different between the VOI file and hardware scene. It's currently not very different. It's not very different from hardware scene when it comes to the throughput of the data path because the network protocol stack is very heavy and most of the operations in the network protocol stack takes a long time. So actually, we have did some performance test but it's not very different from hardware scene. Yeah. Okay. Thank you, everyone.