Hi, I think this could be very useful to a bunch of people.
The only risk is breaking the solo5 interface currently used by mirage and includeos. What about going ahead with the API change, and change mirage and includeos in two steps. First, we just replace all references of read/write(buf) to read/write(0,buf) (we keep assuming there is only 1 NIC). And then we think about how to actually use more than one device in both unikernels. Regarding binding and tender changes (ukvm and virtio on the kernel side); I can work on a virtio prototype and nikhil on the ukvm side. Or, alternatively, we can forget virtio for now. Thanks, Ricardo On Tue, May 22, 2018 at 3:48 AM, nikhil ap <niks3...@gmail.com> wrote: > Hi guys, > > Currently solo5/ukvm supports only one NIC. I wanted to know your thoughts > on supporting multiple NICs. This is really important and essential > requirement when trying to run on IncludeOS unikernels which is heavily > focused on networking and NFV. > > After talking to Ricardo, I understand that the difficulty is in coming up > with a new API. I wanted to start off the discussion. > The obvious solution is to specify the NIC index (an int) in the API. It > could look something like this: > > solo5_result_t solo5_net_write(int index, const uint8_t *buf, size_t > size); > solo5_result_t solo5_net_read(int index, uint8_t *buf, size_t size, size_t > *read_size); > > The number of NICs supported could be specified during the startup in > solo5_app_main. > > Also, when we are supporting shared memory and ring buffer, we can > register a struct block having shmstreams, eventfds per NIC. We can then > feed the events to the iothread's epoll. > > I understand that the requirement for the simplicity of the APIs so we can > improve on it every iteration while having the feature ready. I would > > -- > Regards, > Nikhil >
