Differences

This shows you the differences between two versions of the page.

--- nndocs:sandbox [2024/09/19 21:09] – [Host Numbers] speculate less naptastic
+++ nndocs:sandbox [2025/05/04 02:15] (current) – [Networks] make a table. Might be fun. naptastic
@@ Line 11: / Line 11: @@
 | Food | cherry |
-====IQNs====
+====IQN and NQN====
-We do iSCSI Qualified Names by the book, but as simply as possible. A couple of examples:
+We do iSCSI and NVMe Qualified Names by the book, but as simply as possible. A couple of examples:
-    iqn.2014-08.rocks.narf.sadness
+    iqn.2014-08.rocks.narf.southpark:duckling
-    iqn.2004-12.com.naptastic.quirk
+    nqn.2004-12.com.naptastic.quirk:68
-IQNs can also have :more.stuff on the end. I can't come up with a use case, since hostnames are already fully-qualified and unique.
+  * 'iqn' for iSCSI or 'nqn' for NVMe-oF
+  * YYYY-MM is the month in which the domain was registered.
+  * the hostname is in backwards DNS order
+  * :initiator or :namespace
-There are still some :01 suffixes lurking around the network. Fix them or don't; just don't make new ones.
+From the perspective of a host, every storage bus has a number. Bus 0 is the local PCI bus. Bus 1 is for the host acting as an initiator. Higher numbers are for a host acting as a target. Connections go like this:
-Ideally, /etc/iscsi/initiatorname.iscsi gets the right value as part of system provisioning, and the target only ever has to use the host's correct name. There's a strong warning about changing IninitatorName in that file; if you're changing it to the correct value (i.e., the value in the target's ACL) then it's fine.
+  iqn.2004-12.com.naptastic.rocky:01 -> iqn.2014-08.rocks.narf.southpark:68
-====NQNs====
+Since rocky's host number is 68, any other host wishing to share storage with rocky should do so on their own target bus number 68. The network is responsible to connect rocky's bus 01 with southpark's bus 68.
-NQNs: nqn.2014-08.rocks.narf.hostname is the whole thing. No :01 or any of that jazz, at least not yet.
 ====Interfaces====
@@ Line 36: / Line 38: @@
   * mlxX: mlx ports when they are configured for Ethernet operation
+----
 =====Numbers=====
@@ Line 46: / Line 50: @@
 === MAC addresses for the quad-port gigabit cards ===
-This was in shark, and is now in a drawer:
+southpark en(0..3):
       hardware ethernet 00:10:18:f8:02:20;
       hardware ethernet 00:10:18:f8:02:22;
@@ Line 52: / Line 56: @@
       hardware ethernet 00:10:18:f8:02:26;
-duckling en(0..3)
+in a drawer:
       hardware ethernet 00:10:18:f8:2e:10;
       hardware ethernet 00:10:18:f8:2e:12;
       hardware ethernet 00:10:18:f8:2e:14;
       hardware ethernet 00:10:18:f8:2e:16;
+====IPv6====
+IPv6 local unique addresses have four parts:
+  - 8 bits of fixed prefix (fd)
+  - 40 bits of pseudorandom prefix
+  - 16 bits of subnet
+  - 64 bits of GUID
+My top 48 bits are going to be fd20:4e41:5020. Subnet bits should match their Infiniband subnet. Host bits come from the hardware address.
 ====IP Addresses====
@@ Line 68: / Line 81: @@
 ====Networks====
+^ Network ^ IPv4 Range ^ IPv6 Range ^ IB Subnet ^ VLAN ^ VXLAN IP ^ VXLAN ID ^
+| green | 172.20.0/22 | fd20:4e41:5020:ffff::/64. | ffff | | 225.172.20.64 | 64 |
   * 0-3/22: "green": all emo* and eth* devices should get bridged to this network.
@@ Line 73: / Line 90: @@
     * 1: .0-255 contains IPMI interfaces and nothing else right now
     * 2: .0-255 is for unassigned DHCP hosts
-    * 3: .0-254 is for VMs that are expected to only run on a specific physical host. Hosts
+    * 3: .0-254 is for VMs that are expected to only run on a specific physical host.
-      * .32-39: butler
       * .72-79: carbon
       * .80-87: duckling
@@ Line 133: / Line 149: @@
   * 35: xp-pe (tbh idk if this still exists)
   * 36: tf2
+  * 68: rocky (VM with SR-IOV parts)
+----
 =====Big Idea Dumping Ground=====
+====SoC on a PCI card====
+Mostly this is to enable other projects. It needs at least these features:
+  * reasonable amount of CPU and DRAM
+  * PCIe 3.0 x1 or better
+  * Internal ports:
+    - m.2 slot
+    - 40-pin with GPIO, I2C, etc...
+    - LP-DIMM
+  * External ports:
+    - HDMI
+    - gigabit Ethernet
+    - (2) USB 3.1
+The card presents itself to its host as one or more devices. It can pass through its USB host adapter, network adapter, and m.2 slot, and act as a GPU. It supports SR-IOV. You can boot off it. With the right hardware support, it should be able to stay awake while the host powers off or reboots.
 ====PCIe networking====
 These products:
@@ Line 146: / Line 181: @@
     * OCP slot, maybe?
     * PCI and ISA bridges
+  - USB device holder
+  - SATA/SAS and NVMe backplanes
+The paradigm is "assign devices to hosts" rather than "hosts communicating". The storage shelves don't need to have file services or even know about filesystems. They will show up as a PCI device with storage attached to whatever system they're connected. This is a "peripheral area network" and if CXL becomes part of the mix, it's "memory area network" as well.
+Everything except retimer cards needs an API and UI for managing things.
 ====Better Audio Stack====
@@ Line 158: / Line 199: @@
 ====Better DAW====
 Core concept is a piece of virtual tape that's infinitely long, infinitely wide, and has an infinite number of tape heads that can all be accessed remotely. A recording session is a server you log into, send recorded audio, receive mixed audio, and update a database of what should play when and with what settings.
+====RDMA to a Commodore 64====
+The 6502 can't drive the C64's memory anywhere near full-speed, but the ROM port has a DMA pin, so a DMA-capable cartridge can do impossibly cool things. I'd like to find a good demo playback engine that already exists, and adapt it to play back data being streamed in over a network.
 ====Better Mixer====
 FIXME