Hi,
There is solo5_net_info to get details about the nic. What about extending
it with idx and the net_info struct with all the relevant details. Like
below. Would that address the concerns? Initially, unikernels could
enumerate all nics to get the one they want (if they are looking up based
on something that is not index).
Thanks,
Ricardo
struct solo5_net_info {
uint8_t mac_address[SOLO5_NET_ALEN];
size_t mtu; /* Not including Ethernet header */
};
/*
* Retrieves information about the network device. Caller must supply space for
* struct solo5_net_info in (info).
*/
void solo5_net_info(int idx, struct solo5_net_info *info);
On Wed, May 30, 2018, 9:27 AM Jedi Chen <jedi...@live.com> wrote:
> 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 <takayuki.im...@gmail.com> 写道：
> >
> > 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
>
