Hi,
Similar changes need to be done to allocate a specific MAC address to one of
multiple Netif devices??
Many thanks,
--
Takayuki Imada
On 5/23/18 2:59 AM, Ricardo Koller wrote:
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
<mailto: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_tsolo5_net_write(int index, constuint8_t*buf, size_tsize);
solo5_result_tsolo5_net_read(int index, uint8_t*buf, size_tsize,
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
