# Fabric's Basic Logic Done
Date: 2025-06-06

## Goals and expectations
Complete the fabric's code.

## Results
Done.

And also revised the directory layout (swapped `fabric/` and `src/`).

As a bonus, I also modularized the interfaces' code, making it cleaner
and easier to maintain.

And as a second bonus, I completed the drop logic.

## Packet dropping
Packet dropping can be caused by two issues:

1. The packet memory is full, in which case the hub will notify all
   interfaces to drop their packets.
2. The destination's packet queue is full, in which case the hub will
   drop the packet by immediately reclaiming the slot via the reuse
   logic.
   
There are a few scenarios for which this can play out.  Notably, if both
the packet memory and the destination's packet queue is full, and the
destination was full before the packet memory, then the **hub** will
drop the packet instead of the source interface.

## Reflections
1. Keep the momentum alive.  I kept the momentum I gained yesterday
   alive by actively coding today, this helped me pick up my previous
   thoughts.
2. Small rewards go a long way.  I recently showed some people the
   ROSE repo, they didn't read much code, but they were obsessed with
   the devlogs and the README and how organized the entire project is.
   This boosted my confidence in thinking that ROSE could be a
   game changer for me - I wanted it to become something that people
   can appreciate, even if they're not devs, even if they don't read
   the code.  I enjoyed their praise, and I'm preparing myself to
   uphold that.
3. Simplify the logic.  Much of today's code was linking different
   modules together and having internal states within the modules to
   manage the operations.  Most of the time, the data is already
   available, and there's no reason to stall it for an additional
   cycle to buffer it.
4. HDL is better for design meant for hardware.  This isn't
   ROSE-specific, but rather a thought that I came across while
   implementing the new ARCANE load balancing algorithm for an `ns-3`
   sim.  It would've been much cleaner to implement a
   hardware-targeting algorithm in HDL than in a language like C++.
   For example, the three states of ARCANE (explore, normal and
   freeze) would be perfectly implemented by an FSM.  While the C++
   sim would have to schedule timeouts using very explicit (and
   seemingly unnecessarily complex) code, SystemVerilog would embrace
   that by design.

## Final thoughts
Finally! After more than a month of intermittent coding, I'm close to
completing an implementation for the fabric.  Just some sim tests and
I can begin working on the Linux code for the hosts.

I love coding, I love writing my thoughts down, in code or in plain
words.  It's the proof of my existence.  I'm here to leave a mark, for
those who'd like to see how I do it.

> C'est cela l'amour, tout donner, tout sacrifier sans espoir de
> retour.

### What is such a thing as love that doesn't hope for anything in return?
It's that the love is for a bigger picture.  We'd always hope for
something in return, whether that's tangible or intangible, whether
that's spontaneous or given to by someone else.  But the scale of the
hope changes when we have love.  With it, we see a bigger picture -
how that love is impulsive, how that love drives us forward, and how
in the broader view, it makes us better.

## Next steps
Testing.  I'm sure when I throw real traffic at my code, it will go
wrong in ways.

Notably, I should test the drop logic with different scenarios:
bursts, incast, and heavy background flows.  Simulating congestion is
my thing (but, of course, we won't be running something as complex as
an AllReduce workload).
