Hi, Can we use netdev struct to replace the index? Because the net device may have different parameters, not merely index.
Regards, > 在 2018年5月30日，21:04，Takayuki Imada <[email protected]> 写道： > > 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 <[email protected] >> <mailto:[email protected]>> 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
