Add DuplicateDevice

[Centaurus99]

No description provided.

[un-lock-able]

When the device has decided that a packet should be duplicated, where should the duplicated packet go? Should it be at the head of the queue or at the tail of the queue, or a random position within?

[Centaurus99]

When the device has decided that a packet should be duplicated, where should the duplicated packet go? Should it be at the head of the queue or at the tail of the queue, or a random position within?

@un-lock-able We can implement this DuplicateDevice in the simplest method. We can refer to LossDevice and check if it is a duplicate when dequeuing. If it is, we copy the packet and send it out, while leaving the original packet in place.

For more complex duplicate modes, such as a combination of duplicate and reordering, we can implement a new device in the future to handle it.

[un-lock-able]

I'm now writing the DuplicateDeviceEgress and I have found that unlike DelayDevice and LossDevice, there is no DuplicatePattern, DuplicateTrace and DuplicateTraceConfig defined in the netem_trace crate. Should I create them in netem_trace or define them somewhere in this project?

[BobAnkh]

I'm now writing the DuplicateDeviceEgress and I have found that unlike DelayDevice and LossDevice, there is no DuplicatePattern, DuplicateTrace and DuplicateTraceConfig defined in the netem_trace crate. Should I create them in netem_trace or define them somewhere in this project?

As for this question, we should define all trace-relavant things in netem-trace crate.

[minhuw]

What a pity there is no such thing as a formal specification of network emulation trace. Maybe we could write one to make things like alignment between loss / throughput / delay more predictable.

[BobAnkh]

What a pity there is no such thing as a formal specification of network emulation trace. Maybe we could write one to make things like alignment between loss / throughput / delay more predictable.

I think it may be enough for alignment if the calibrated start time is implemented.

[BobAnkh]

@un-lock-able I have published a new version (v0.3.4) of the crate netem-trace containing the packet duplicate trace so that you can continue on this issue now.

[un-lock-able]

To duplicate a packet, should I add a trait bound of Clone on the trait Packet or should I manually copy the content the packet in the DuplicateDeviceEgress?

[BobAnkh]

To duplicate a packet, should I add a trait bound of Clone on the trait Packet or should I manually copy the content the packet in the DuplicateDeviceEgress?

I think we can just make Packet Cloneable? cc @minhuw

[minhuw]

Yes, we could make Packet Cloneable. Each packet type needs to has its own Clone implementation because different drivers may have different memory management schema. For example, StdPacket could use the standard allocator, but XDPPacket are all allocated from pre-registered chunks. I'll implement Clone for XDPPacket later.