Replies: 9 comments
-
What to do first :
|
Beta Was this translation helpful? Give feedback.
-
Poke @gkatsikas I need to solve this to implement the Metron monitoring (for the timestamp). What's your take on this? Others are welcome to share their thoughts of course. |
Beta Was this translation helpful? Give feedback.
-
The Click-like solution seems more elegant to me. Maybe we could enrich |
Beta Was this translation helpful? Give feedback.
-
But then how does, eg, SetTCPChecksum finds the downstream transmitter(s).
One idea would be to look downstreamfrom SetTCPChecksum for elements that can cast themselves as "SetTCPChecksum", and then ask the casted one to enable the functionnality. |
Beta Was this translation helpful? Give feedback.
-
Well, I had only thought about the receiving side up to that point. There, it is feasible to check if a timestamp/checksum is already there, and compute it otherwise. On element output, the timestamp/checksum is guaranteed to be there. Enabling offloading on the input device is orthogonal. It could either be automatic (e.g. On the transmission side, it is not as straightforward. What if some packets go to a device that support offloading, and some go to a device that does not support it? Moreover, it feels wrong to have a Maybe the cleanest thing to do is add all that functionality to |
Beta Was this translation helpful? Give feedback.
-
I generally agree with the Click-like solution you discussed and specifically with the latest post by @cffs. |
Beta Was this translation helpful? Give feedback.
-
I like @gkatsikas idea to put all offloading stuff into a dedicated component. I would prefer to have this as a dedicated Click element(s) as apposed to a C/C++ library. |
Beta Was this translation helpful? Give feedback.
-
The dedicated element would be closely related to the I/O one. Isn't it better to have a library in lib/ ?
In the case of the Timestamp, the software backup is only one line 'p->set_timestamp_anno(Timestamp::now());' so I doubt a library would be suitable for one line. I'll make a proposal as a pull request. |
Beta Was this translation helpful? Give feedback.
-
I was thinking more in the lines of a generic OffLoad component similar to how you use DPDKInfo and DPDKDevice at the moment (as @cffs already suggested). But reading over this discussion again the problem you already pointed out for TX still exist. Looking downstream for casted "SetTCPChecksum" devices is also going to be problematic if there are multiple downstream ToXXDevice where possibly not all support offloading. So you'll have to end up with Offload elements right after FromDevice and right before ToDevice, which couples it directly to the IO device, so the suggestion of a library in /lib is probably better as you suggested :) |
Beta Was this translation helpful? Give feedback.
-
There are basically 2 ways :
The second one is more "Click-like" because the logic is specified by elements. But how to make the element "discuss" to establish that the feature is supported by the upfront hardware?
Beta Was this translation helpful? Give feedback.
All reactions