DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Loftus, Ciara" <ciara.loftus@intel.com>
To: Ferruh Yigit <ferruh.yigit@amd.com>,
	Stephen Hemminger <stephen@networkplumber.org>,
	Long Li <longli@microsoft.com>,
	"Zhang, Qi Z" <qi.z.zhang@intel.com>
Cc: Ophir Munk <ophirmu@nvidia.com>, "dev@dpdk.org" <dev@dpdk.org>,
	"Thomas Monjalon" <thomas@monjalon.net>,
	Aaron Conole <aconole@redhat.com>, dpdklab <dpdklab@iol.unh.edu>,
	David Marchand <david.marchand@redhat.com>
Subject: RE: [PATCH] tap: fix build of tap_bpf_program
Date: Wed, 26 Jul 2023 09:15:16 +0000	[thread overview]
Message-ID: <MW4PR11MB5872D4DE11E717A64EDA17D88E00A@MW4PR11MB5872.namprd11.prod.outlook.com> (raw)
In-Reply-To: <90916e3a-05a2-f601-1d3d-985dd31d7419@amd.com>

> On 7/20/2023 8:45 AM, Ferruh Yigit wrote:
> > On 7/19/2023 5:12 PM, Stephen Hemminger wrote:
> >> On Wed, 19 Jul 2023 11:03:36 +0100
> >> Ferruh Yigit <ferruh.yigit@amd.com> wrote:
> >>
> >>> On 7/19/2023 11:00 AM, Ferruh Yigit wrote:
> >>>> On 7/17/2023 8:15 PM, Stephen Hemminger wrote:
> >>>>> The tap_bpf_program.c is not built as part of normal DPDK
> >>>>> EAL environment. It is intended to be built standalone
> >>>>> and does not use rte_common.h.
> >>>>>
> >>>>> This reverts the related change from
> >>>>> commit ef5baf3486e0 ("replace packed attributes")
> >>>>>
> >>>>> Note: this patch will cause expected warnings from checkpatch
> >>>>> because the code involved is not used directly in DPDK environment.
> >>>>>
> >>>>> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> >>>>>
> >>>>
> >>>> Agree, this seems done by mistake as part of batch update,
> >>>>
> >>>> Acked-by: Ferruh Yigit <ferruh.yigit@amd.com>
> >>>>
> >>>>
> >>>> But I can't update the bpf file at all, if I am not missing something I
> >>>
> >>> * I can't *compile* the bpf file ...
> >>>
> >>>> am not sure if we should get just this update or have a patch/patchset
> >>>> that fixes the build.
> >>>>
> >>>> @Ophir, how the bpf file is compiled? And did you test it recently?
> >>>>
> >>>> I am using command from the documentation:
> >>>> `clang -O2 -emit-llvm -c tap_bpf_program.c -o - | llc -march=bpf
> >>>> -filetype=obj -o tap_bpf_program.o`
> >>
> >> It looks like this won't work because it was expecting to be able
> >> to find header files from older version of iproute2.  These are not
> >> distributed, and the change to support libbpf in iproute2 makes the
> >> current versions not work.
> >>
> >> As a stopgap, will look back in history and see what version of header
> >> files will at least get a working build.
> >>
> >> From there, need to replace how the conversion of .o to array works.
> >> Would prefer to use dlopen() to read the ELF file rather than expecting
> >> developers to hack together their own tools.
> >>
> >> Not sure how much effort is really needed here. This is only being
> >> used for the case of rte_flow with multiq RSS. Probably, no one ever
> >> used it.
> >>
> >
> > Should we remove the file, instead of fixing '__rte_packed'?
> >
> 
> +Long, and af_xdp maintainers,
> 
> @Long, do you know if this bfp code is still in use somewhere, if so is
> the user interested in fixing/maintaining the code?
> 
> 
> @Ciara, @Qi, do you see any benefit to keep/extend this kind of bfp file
> usage? Do you think is this something to invest more?

If the code is still being used I would agree with Stephen that using dlopen or libbpf to load the eBPF code would be preferable. The current steps are difficult to follow. 

      parent reply	other threads:[~2023-07-26  9:15 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-17 19:15 Stephen Hemminger
2023-07-19 10:00 ` Ferruh Yigit
2023-07-19 10:03   ` Ferruh Yigit
2023-07-19 10:09     ` Ferruh Yigit
2023-07-19 16:12     ` Stephen Hemminger
2023-07-20  7:45       ` Ferruh Yigit
2023-07-20  9:08         ` Ferruh Yigit
2023-07-25 22:49           ` Long Li
2023-07-26  9:15           ` Loftus, Ciara [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=MW4PR11MB5872D4DE11E717A64EDA17D88E00A@MW4PR11MB5872.namprd11.prod.outlook.com \
    --to=ciara.loftus@intel.com \
    --cc=aconole@redhat.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=dpdklab@iol.unh.edu \
    --cc=ferruh.yigit@amd.com \
    --cc=longli@microsoft.com \
    --cc=ophirmu@nvidia.com \
    --cc=qi.z.zhang@intel.com \
    --cc=stephen@networkplumber.org \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).