From: Stefano Brivio <sbrivio@redhat.com>
To: William Tu <u9012063@gmail.com>
Cc: Ben Pfaff <blp@ovn.org>, Matteo Croce <mcroce@redhat.com>,
Pravin B Shelar <pshelar@ovn.org>,
Justin Pettit <jpettit@vmware.com>,
Greg Rose <gvrose8192@gmail.com>, netdev <netdev@vger.kernel.org>,
"<dev@openvswitch.org>" <dev@openvswitch.org>,
Jiri Benc <jbenc@redhat.com>, Aaron Conole <aconole@redhat.com>,
Joe Stringer <joe@wand.net.nz>
Subject: Re: [PATCH RFC net-next] openvswitch: Queue upcalls to userspace in per-port round-robin order
Date: Tue, 14 Aug 2018 17:25:16 +0200 [thread overview]
Message-ID: <20180814172516.14ec4d5e@epycfail> (raw)
In-Reply-To: <CALDO+SZ=y=LHmwic0Fh260FUxV6z-KUOVOf7WJPkNDeTE6BxNQ@mail.gmail.com>
Hi William,
On Fri, 10 Aug 2018 07:11:01 -0700
William Tu <u9012063@gmail.com> wrote:
> > int rr_select_srcport(struct dp_upcall_info *upcall)
> > {
> > /* look up source port from upcall->skb... */
> > }
> >
> > And we could then easily extend this to use BPF with maps one day.
> >
> >
> Hi Stefano,
>
> If you want to experiment with BPF, Joe and I have some prototype.
> We implemented the upcall mechanism using BPF perf event helper function
> https://github.com/williamtu/ovs-ebpf/blob/master/bpf/datapath.c#L62
>
> And there are threads polling the perf ring buffer to receive packets from
> BPF.
> https://github.com/williamtu/ovs-ebpf/blob/master/lib/perf-event.c#L232
Interesting, thanks for the pointers!
> If I follow the discussion correctly, before upcall, you need to queue
> packets based on different configurations (vport/hash/vni/5-tuple/...)
> and queue to different buckets when congestion happens.
Yes, correct.
> In this case, you
> probably needs a BPF map to enqueue/dequeue the packet.BPF queue map is
> not supported yet, but there is patch available:
> [iovisor-dev] [RFC PATCH 1/3] bpf: add bpf queue map
>
> So how to enqueue and dequeue packets depends on user's BPF implementation.
> This allows fairness scheme to be extensible.
For the moment being we'll try to ensure that BPF can be plugged there
rather easily. I see the advantage, but I'd rather do this as a second
step.
--
Stefano
next prev parent reply other threads:[~2018-08-14 18:13 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-04 14:23 [PATCH RFC net-next] openvswitch: Queue upcalls to userspace in per-port round-robin order Matteo Croce
[not found] ` <20180704142342.21740-1-mcroce-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2018-07-10 18:31 ` Pravin Shelar
2018-07-16 16:54 ` Matteo Croce
2018-07-31 19:43 ` Matteo Croce
[not found] ` <CAGnkfhyxQSz=8OsgTsjR3NfZ2FPwv+FjPZNPEY5VHZRsEiQ68w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-07-31 22:06 ` Ben Pfaff
2018-08-03 16:52 ` Stefano Brivio
2018-08-03 23:01 ` Ben Pfaff
2018-08-04 0:43 ` Stefano Brivio
2018-08-04 0:54 ` Ben Pfaff
2018-08-10 14:11 ` William Tu
2018-08-14 15:25 ` Stefano Brivio [this message]
2018-07-31 23:12 ` Pravin Shelar
2018-08-07 13:31 ` Stefano Brivio
2018-08-07 13:39 ` Stefano Brivio
2018-08-15 7:19 ` Pravin Shelar
[not found] ` <CAOrHB_DaA-+J=jzNOdQiUYrA7RJi30HmRESjsmGs7_z1ffpVOA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-08-16 21:07 ` Stefano Brivio
2018-09-26 9:58 ` Stefano Brivio
2018-09-28 17:15 ` Pravin Shelar
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=20180814172516.14ec4d5e@epycfail \
--to=sbrivio@redhat.com \
--cc=aconole@redhat.com \
--cc=blp@ovn.org \
--cc=dev@openvswitch.org \
--cc=gvrose8192@gmail.com \
--cc=jbenc@redhat.com \
--cc=joe@wand.net.nz \
--cc=jpettit@vmware.com \
--cc=mcroce@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=pshelar@ovn.org \
--cc=u9012063@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.