On Fri, Sep 6, 2024 at 8:12 PM Morten Brørup <m...@smartsharesystems.com> wrote:
>
> > From: Ferruh Yigit [mailto:ferruh.yi...@amd.com]
> > Sent: Friday, 6 September 2024 16.12
> >
> > On 9/6/2024 11:04 AM, Morten Brørup wrote:
> > >> From: Ferruh Yigit [mailto:ferruh.yi...@amd.com]
> > >> Sent: Friday, 6 September 2024 10.54
> > >>
> > >> On 9/5/2024 3:01 PM, Jerin Jacob wrote:
> > >>> On Thu, Sep 5, 2024 at 3:14 PM Morten Brørup
> > >>> <m...@smartsharesystems.com>
> > >> wrote:
> > >>>>
> > >>>>> From: David Marchand [mailto:david.march...@redhat.com]
> > >>>>> Sent: Thursday, 5 September 2024 11.03
> > >>>>>
> > >>>>> On Thu, Sep 5, 2024 at 10:55 AM Morten Brørup
> > >>>>> <m...@smartsharesystems.com>
> > >>>>> wrote:
> > >>>>>>
> > >>>>>>> From: David Marchand [mailto:david.march...@redhat.com]
> > >>>>>>> Sent: Thursday, 5 September 2024 09.59
> > >>>>>>>
> > >>>>>>> On Wed, Sep 4, 2024 at 8:10 PM Stephen Hemminger
> > >>>>>>> <step...@networkplumber.org> wrote:
> > >>>>>>>>
> > >>>>>>>> The API's in ethtool from before 23.11 should be marked stable.
> > >>>>>>>
> > >>>>>>> EAL* ?
> > >>>>>>>
> > >>>>>>>> Should probably include the trace api's but that is more complex
> > >> change.
> > >>>>>>>
> > >>>>>>> On the trace API itself it should be ok.
> > >>>>>>
> > >>>>>> No!
> > >>>>>
> > >>>>> *sigh*
> > >>>>>
> > >>>>>>
> > >>>>>> Trace must remain experimental until controlled by a meson option,
> > >>>>>> e.g.
> > >>>>> "enable_trace", whereby trace can be completely disabled and omitted
> > from
> > >> the
> > >>>>> compiled application/libraries/drivers at build time.
> > >>>>>
> > >>>>> This seems unrelated to marking the API stable as regardless of the
> > >>>>> API state at the moment, this code is always present.
> > >>>>
> > >>>> I cannot foresee if disabling trace at build time will require changes
> > >>>> to
> > >> the trace API. So I'm being cautious here.
> > >>>>
> > >>>> However, if Jerin (as author of the trace subsystem) foresees that it
> > will
> > >> be possible to disable trace at build time without affecting the trace
> > >> API,
> > I
> > >> don't object to marking the trace API (or some of it) stable.
> > >>>
> > >>> I don't for foresee any ABI changes when adding disabling trace
> > >>> compile time support. However, I don't understand why we need to do
> > >>> that. In the sense, fast path functions are already having an option
> > >>> to compile out.
> > >>> Slow path functions can be disabled at runtime at the cost of 1 cycle
> > >>> as instrumentation cost. Having said that, I don't have any concern
> > >>> about disabling trace as an option.
> > >>>
> > >>
> > >> I agree with Jerin, I don't see motivation to disable slow path traces
> > >> when they can be disabled in runtime.
> > >> And fast path traces already have compile flag to disable them.
> > >>
> > >> Build time configurations in long term has problems too, so I am for not
> > >> using them unless we don't have to.
> > >
> > > For some use cases, trace is dead code, and should be omitted.
> > > You don't want dead code in production systems.
> > >
> > > Please remember that DPDK is also being used in highly optimized embedded
> > systems, hardware appliances and other systems where memory is not abundant.
> > >
> > > DPDK is not only for cloud and distros. ;-)
> > >
> > > The CI only tests DPDK with a build time configuration expected to be
> > > usable
> > for distros.
> > > I'm not asking to change that.
> > > I'm only asking for more build time configurability to support other use
> > cases.
> > >
> >
> > I see, but that build time configuration argument exists in multiple
> > aspects. And with meson switch we lean to dynamic configuration approach.
>
> It can be rte_config.h instead of Meson option. Either is perfectly fine with
> me.
>
> >
> > When a build time config introduced, again and again we are having cases
> > that specific code enabled with compile time macro broken and nobody
> > noticed.
>
> I acknowledge this risk.
if we use
if (0)
{
}
scheme instead of #ifdef scheme.
The compiler will check this leg even it is not active.
>
> Trace doesn't interact with anything, so I consider the risk extremely low in
> this case.
>
> > Having code enabled always and configured in runtime produces more
> > robust deliverable.
>
> The same can be said about the Linux kernel, but yet it is configurable.
>
> >
> > We are aware that DPDK is used in embedded device, but they are not
> > mostly very resource restricted devices, is it really matter to have a
> > few megabytes (I didn't check but I expect this the max binary size can
> > increase with tracing code) larger DPDK binary, does it really makes any
> > difference?
>
> Code size also affects system boot time, because those superfluous megabytes
> take time to decompress when booting from FLASH memory.
> For reference, the size of our system image (including Linux kernel, OpenSSL,
> the DPDK application, webserver, GUI, CLI, SNMP and everything) is 12 MB
> compressed.
>
> From a security aspect, trace also increases the attack surface and can
> potentially assist a hacker trying to break into a system.
>
