[yoursunny]

NIC_Basic is a Virtual Function (VF) on the ConnectX-6 Ethernet adapter. The hardware Ethernet adapter is shared among many VFs, and it determines which VF shall receive an incoming packet by matching the destination address. Therefore, NIC_Basic cannot receive Ethernet frames whose destination address differs from its own address.

[yoursunny]

it seems as if packets are filtered by MAC learning on the L2Bridge type network

What observation led you to this conclusion?

What are you trying to do, how it behaved, and how do you expect it to behave?

[yoursunny]

When you invoke slice.submit(), the slice object (and the associated nodes, links, intfs) will not auto-update.
You need to do another slice = fablib.get_slice(name=slice.get_name()) (and re-retrieve enclosed nodes, link, intfs if needed) to obtain updated information.

[yoursunny]

I just noticed this:

Since FABLib v1.4, API documentation is hosted at https://fabric-fablib.readthedocs.io/.
Older version of FABLib API documentation is at https://learn.fabric-testbed.net/docs/fablib/fablib.html.

Can you add a note on top of the “older version” page, pointing to the v1.4 docs?
I have bookmarked the “older version” page previously, and have been wondering why it doesn’t update, until now.
I suppose some others may have done the same.

[yoursunny]

ifconfig is deprecated since Ubuntu 16.

Try ip link or ip addr command.

[yoursunny]

I faced the same issue today.
I found this method effective:

1. File – Hub Control Panel
2. Stop My Server
3. Logout
4. Login again

YMMV

[yoursunny]

Ilya Baldin wrote:

I know for a fact we have folks using DPDK on the testbed with all three NIC types

Yeah, that’s me.
All three NIC types can support most DPDK features, but for NIC_Basic you must use the assigned MAC address and cannot use other MAC addresses.

You would need linux-image-generic for the kernel module and libibverbs-dev to enable DPDK net_mlx5 driver.
In FABlib script, you can insert this step, after slice.submit() and before building DPDK:

execute_threads = {}
for node in slice.get_nodes():
    execute_threads[node] = node.execute_thread(f'''
        sudo apt update
        sudo DEBIAN_FRONTEND=noninteractive apt full-upgrade -y
        sudo DEBIAN_FRONTEND=noninteractive apt install -y –no-install-recommends libibverbs-dev linux-image-generic jq
        sudo reboot
    ''')
for thread in execute_threads.values():
    thread.result()
slice.wait_ssh(progress=True)

[yoursunny]

I see indentation errors in the two snippets above.

Also, there’s no Preview button so that it’s impossible to know whether my content would render correctly before publishing.

[yoursunny]

We have on the roadmap support for ERO (explicit route objects) so that you can have your traffic take the ‘scenic route’ as you say

This will be very useful.

You can on your own add delay to your traffic using traditional Linux tc tools.

This would not work well in speeds higher than 10 Gbps.

running Iperf I saw the max bandwidth I can get in VMs is around 19-20 Gbps

You might get higher speeds if you request dedicated NIC.
I can get 60 Gbps on ConnectX-6 dual-port 100 Gbps and 33 Gbps on ConnectX-5 dual-port 25 Gbps, tested in SALT location.
This number is “goodput” reported by my DPDK-based program, and it’s the sum of traffic in both directions.
iperf3 is unidirectional traffic so it could be half of this.

[yoursunny]

I agree that knowing the physical topology may be useful, especially when the slice spans multiple sites.
For example, if I create a slice with L2PTP link between STAR and UCSD, there are multiple possible paths, and it’s good to know which path my traffic is taking.

Add onto this, it’s useful to have observability into other traffic on the same links.
The link between WASH and STAR has 100 Gbps capacity.
When I benchmark my app running over L2PTP link between these two sites, I may receive throughput of 60 Gbps.
This could be caused by issues in my application (e.g. congestion control algorithm not tuned for >10ms RTT), or caused by other competing traffic on the link.
If FABRIC portal can include a diagram of near-realtime link utilization, I can better understand which one is the more likely cause.

In another angle, it’s also useful to be able to control the physical topology.
Suppose I want to develop my congestion control algorithm over a high latency link, the longest RTT can be achieved today is between MASS and UCSD.
If I can specify the physical topology as part of slice definition, I could make a link to take a scenic route such as WASH-ATLA-DALL-LOSA-SALT-KANS-STAR, which provides a longer natural latency.

[yoursunny]

Can you enable Markdown too?
Both GitHub and Jupyter have Markdown, so more developers are already familiar with it.

[yoursunny]

The web portal login has 1-hour timeout. When it reaches 1 hour, you’ll still see you are logged in, but you cannot do anything.

You have to click logout and then login again. After that, you can see your slices or delete them normally.

I consider this a portal bug. It should keep the user logged in for as long as the page is open. If servers side reports the login has expired, the client side should automatically display “login” button instead of “logout” button.

[yoursunny]

It’s very difficult to write/share code snippets on this forum. Python indentation is always messed up.

Maybe operator should switch to a different forum software? Vanilla and Discourse have better UX.

[yoursunny]

You are missing the step “Import the FABlib Library”.

Look at hello_fabric notebook and paste the three lines in Step 2 to the top of your script.

• This reply was modified 1 year, 7 months ago by yoursunny.
• This reply was modified 1 year, 7 months ago by yoursunny.

[yoursunny]

Yes, the slice(s) eventually became StableOK after more than 4 hours.

I was disappointed to find that FABNETv6 does not allow access to the Internet despite having public addresses, so that I still have to use the (supposedly) slow management network for any Internet access.

[Author]

Posts