Which model for hardware offloading? about fastclick HOT 9 CLOSED

What to do first :

• Hardware timestamp + software backup in FromDPDKDevice
• Support for RX/TX checksum offloading

from fastclick.

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.

from fastclick.

The Click-like solution seems more elegant to me. Maybe we could enrich DPDKDevice with more functionality so that offloading features can be queried/set from various elements at configure/initialization time.

from fastclick.

But then how does, eg, SetTCPChecksum finds the downstream transmitter(s).
Eg.

SetTCPChecksum -> Something -> classifying :: Classifier (...) ;
classifying[0] -> ToDPDKDevice(1);
classifying[1] ->  Something -> ToDPDKDevice(2)

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.

from fastclick.

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. SetTCPChecksum would look at all its parent input devices, and try to enable offloading), or manual (by adding parameters directly to FromDPDKDevice).

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 SetTCPChecksum element after which TCP checksum is still invalid, waiting for some output device to change it further down the path.

Maybe the cleanest thing to do is add all that functionality to FromDPDKDevice and ToDPDKDevice, after all.

from fastclick.

I generally agree with the Click-like solution you discussed and specifically with the latest post by @cffs.
However, the complexity issue of some elements is very important. I wouldn't put the "timestamping" code blindly into FromDPDKDevice, no matter if it is software or hardware based. This is why I implemented the DPDK Flow API extensions of the metron branch in a different library which was simply called by FromDPDKDevice. I believe we should follow the same principle here and generalize that library to a software suite that deals with general offloading stuff. Even the backup software-based solution should be part of that library, thus detached from I/O elements.
Only the configuration parameters and the API to the offloading library will remain in the I/O elements,

from fastclick.

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.

from fastclick.

The dedicated element would be closely related to the I/O one. Isn't it better to have a library in lib/ ?
Or the following is what you suggest?

fd :: FromDPDKDevice();
rules :: DPDKFlow(NIC fd);

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.

from fastclick.

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 :)

from fastclick.