Conversation
Signed-off-by: Jakub Duchniewicz <j.duchniewicz@unsw.edu.au>
Signed-off-by: Jakub Duchniewicz <j.duchniewicz@unsw.edu.au>
Signed-off-by: Jakub Duchniewicz <j.duchniewicz@unsw.edu.au>
Signed-off-by: Jakub Duchniewicz <j.duchniewicz@unsw.edu.au>
Signed-off-by: Jakub Duchniewicz <j.duchniewicz@unsw.edu.au>
Signed-off-by: Jakub Duchniewicz <j.duchniewicz@unsw.edu.au>
Signed-off-by: Jakub Duchniewicz <j.duchniewicz@unsw.edu.au>
Signed-off-by: Jakub Duchniewicz <j.duchniewicz@unsw.edu.au>
Signed-off-by: Jakub Duchniewicz <j.duchniewicz@unsw.edu.au>
Signed-off-by: Jakub Duchniewicz <j.duchniewicz@unsw.edu.au>
Signed-off-by: Jakub Duchniewicz <j.duchniewicz@unsw.edu.au>
Signed-off-by: Jakub Duchniewicz <j.duchniewicz@unsw.edu.au>
Signed-off-by: Jakub Duchniewicz <j.duchniewicz@unsw.edu.au>
Signed-off-by: Jakub Duchniewicz <j.duchniewicz@unsw.edu.au>
17cd4e0 to
861c81b
Compare
Signed-off-by: Jakub Duchniewicz <j.duchniewicz@unsw.edu.au>
|
You appear to have broken all the echo server examples per CI. It would be good to add an example/CI test for this. Same applies to libVMM itself. (My other question: is vswitch a driver or an (Lions)OS component...?) |
Yes, I will add the necessary test, example is in libVMM. Should we also have one here?
I don't foresee running it alone, it should be a plug-and-play component chosen during writing of the |
8f1168b to
61938c0
Compare
Signed-off-by: Jakub Duchniewicz <j.duchniewicz@unsw.edu.au>
What I mean is "does it make more sense as part of LionsOS than sDDF"? |
I don't know where we draw the line between, this is "driver/should be in sDDF" and "this is too high-level for sDDF". I presume current components are crucial enough to be here. This is somewhere in-between as it is an optional system component. |
| eth->racc = RACC_LINEDIS | RACC_IPDIS | RACC_PRODIS; | ||
| /* Add the checksum for known IP protocols */ | ||
| eth->tacc = TACC_PROCHK | TACC_IPCHK; | ||
| //eth->tacc = TACC_PROCHK | TACC_IPCHK; // TODO: disabled because VM does that as well |
There was a problem hiding this comment.
Is enabling hardware checksumming something that can be put into the net driver config?
There was a problem hiding this comment.
Yes, I can extend that. We should probably align that with how it is done for LWIP - currently as #ifdef:
sddf/include/sddf/network/constants.h
Line 34 in 8792b60
There was a problem hiding this comment.
This is more to define if the hardware has support for it, but we should also be able to optionally turn on/off certain hardware features
There was a problem hiding this comment.
@Ivan-Velickovic what are your thoughts - I can add this as part of this PR, or alternatively create a new PR with the option to set/unset that option. Also, what other options would we want to be able to configure dynamically?
|
|
||
| /* This is a name for the 96 bit ethernet addresses available on many | ||
| systems. */ | ||
| struct ether_addr { |
There was a problem hiding this comment.
This is a bit of a duplication of what's already in constants.h. Would it be possible to just extend that rather than redefining here?
There was a problem hiding this comment.
We can, IMO it's not a bad idea to split headers according to what they provide/represent instead of having one big constants.h but I am open to a discussion.
There was a problem hiding this comment.
Yeh I'm not opposed to that either, I believe the firewall includes in LionsOS already separate things out such as ethernet, icmp, tcp, and udp constants: https://github.com/au-ts/lionsos/blob/main/include/lions/firewall/ethernet.h.
Maybe it's worth bringing some of those into sDDF and extending them?
There was a problem hiding this comment.
We would need just what I included here right now. I don't think adding most of them makes sense unless we will use them.
There was a problem hiding this comment.
Yeh probably only ethernet is relevant for sDDF
There was a problem hiding this comment.
Commonalized somewhat - please take a look
|
|
||
| #define VSWITCH_VIRT_PORT (SDDF_NET_MAX_CLIENTS - 1) | ||
|
|
||
| #define NUM_BUFFERS (512) |
There was a problem hiding this comment.
Could this be passed in through the vswitch config?
There was a problem hiding this comment.
this is actually an omission on my side - I have been thinking how to properly define this. This comes from:
sddf/include/sddf/network/config.h
Line 55 in 8792b60
As we initialize the drv_queue_capacity with the number of rx_buffers in SDFgen: https://github.com/au-ts/microkit_sdf_gen/blob/main/src/sddf/net.zig#L251
This was supposed to be temporary - I think this needs to be passed into the elf section through SDFgen.
include/sddf/network/config.h
Outdated
| net_connection_resource_t conn; | ||
| device_region_resource_t data; | ||
| device_region_resource_t data[SDDF_NET_MAX_CLIENTS]; | ||
| uint8_t num_data; |
There was a problem hiding this comment.
Is uint8 enough here? Most systems have more than 255 buffers
There was a problem hiding this comment.
maybe the name is confusing - we can have up to 63 Clients, therefore num_data will be also up to 63.
There was a problem hiding this comment.
Corrected, please take a look.
|
I'll have a proper read through the vswitch implementation later, but a few nitpicks of the surrounding updates |
Signed-off-by: Jakub Duchniewicz <j.duchniewicz@unsw.edu.au>
Signed-off-by: Jakub Duchniewicz <j.duchniewicz@unsw.edu.au>
|
@Courtney3141 I think it's prudent to first merge this, then create a new PR for the new example with 2 echo_server's as there might be a substantial amount of new files. Also, libvmm depends on it and not necessarily on the presence of the sddf example. |
Agreed. |
Adds a vswitch component following #636
Allows for connecting up to 62 clients and one TX/RX Virt pair with the vswitch. Tested with PR: au-ts/libvmm#207 and depends on microkit_sdf_gen PR: au-ts/microkit_sdf_gen#31
The support for connecting vswitches back to back might be added later.