Determine if ethtool package can be dropped in favour of an upstream vendor

[jodh-intel]

The ethtool package:

• https://github.com/kata-containers/runtime/blob/master/virtcontainers/pkg/ethtool/ethtool.go

... originally created under:

• wip: Add support for SRIOV containers/virtcontainers#463

Comes from an upstream project:

• https://github.com/safchain/ethtool

We should determine if we can drop this package an instead vendor-in the official package above.

The upstream appears to have more functionality now than when we imported it.

[jodh-intel]

/cc @mcastelino.

[sboeuf]

We needed only a few things from this package and that's why we copy/pasted what was needed instead of importing the whole thing. If we think we might need those other functionalities from the upstream package, then yes I agree we might reconsider it, and import it directly.

[mcastelino]

@jodh-intel @egernst @sboeuf I would keep the upstream package as we need other ethtool functionality for new use cases that we plan to add to Kata like RDMA support.

[sboeuf]

@mcastelino we're not relying on the upstream package, so you mean we would move to the upstream one, right ?

[jodh-intel]

I'd vote for that if at all possible since, stepping back, we're using a copy of an upstream package. We don't even have dep to tell us if upstream changed (think security fixes).

[amshinde]

Agree, I moved from the vendoring the ethtool package to using a copy of the code to keep the code-base smaller. If we are going to need this for other functionality as well, and as @jodh-intel mentioned we need to consider security fixes, I would vendor in the upstream package.
If no one objects, I'll vendor the upstream.

[sboeuf]

@amshinde I think everybody agreed, you can go ahead and vendor the upstream package !