* Re: [PATCH] cxgbit: use T6 specific macro to set force bit
From: Varun Prakash @ 2017-01-25 6:21 UTC (permalink / raw)
To: David Miller
Cc: bart.vanassche@sandisk.com, target-devel@vger.kernel.org,
netdev@vger.kernel.org, Indranil Choudhury
In-Reply-To: <20170124.152616.964714349603826115.davem@davemloft.net>
On Wed, Jan 25, 2017 at 01:56:16AM +0530, David Miller wrote:
> From: Varun Prakash <varun@chelsio.com>
> Date: Tue, 24 Jan 2017 17:07:02 +0530
>
> > For T6 adapters use T6 specific macro to set
> > force bit.
> >
> > Signed-off-by: Varun Prakash <varun@chelsio.com>
>
> What tree is this for?
>
> You must always indicate this in your PATCH subject text.
Sorry, I missed it. This patch is for Bart's target tree.
^ permalink raw reply
* Re: [net PATCH v5 1/6] virtio_net: use dev_kfree_skb for small buffer XDP receive
From: Jason Wang @ 2017-01-25 5:46 UTC (permalink / raw)
To: John Fastabend, Michael S. Tsirkin
Cc: David Miller, john.r.fastabend, netdev, alexei.starovoitov,
daniel
In-Reply-To: <58882355.70307@gmail.com>
On 2017年01月25日 12:02, John Fastabend wrote:
> On 17-01-24 07:23 PM, Michael S. Tsirkin wrote:
>> On Wed, Jan 25, 2017 at 10:57:12AM +0800, Jason Wang wrote:
>>> On 2017年01月25日 04:08, Michael S. Tsirkin wrote:
>>>> On Tue, Jan 24, 2017 at 02:43:28PM -0500, David Miller wrote:
>>>>> From: "Michael S. Tsirkin"<mst@redhat.com>
>>>>> Date: Mon, 23 Jan 2017 23:08:35 +0200
>>>>>
>>>>>> On Tue, Jan 17, 2017 at 02:19:50PM -0800, John Fastabend wrote:
>>>>>>> In the small buffer case during driver unload we currently use
>>>>>>> put_page instead of dev_kfree_skb. Resolve this by adding a check
>>>>>>> for virtnet mode when checking XDP queue type. Also name the
>>>>>>> function so that the code reads correctly to match the additional
>>>>>>> check.
>>>>>>>
>>>>>>> Fixes: bb91accf2733 ("virtio-net: XDP support for small buffers")
>>>>>>> Signed-off-by: John Fastabend<john.r.fastabend@intel.com>
>>>>>>> Acked-by: Jason Wang<jasowang@redhat.com>
>>>>>> Acked-by: Michael S. Tsirkin<mst@redhat.com>
>>>>>>
>>>>>> I think we definitely want this one in -net as it's
>>>>>> a bugfix.
>>>>> This whole series is a bug fix, we must have adjust_header XDP
>>>>> support in the virtio_net driver before v4.10 goes out, it is
>>>>> a requires base feature for XDP.
>>>> I have to say device resets outside probe have a huge potential
>>>> to uncover hypervisor bugs.
>>> Maybe not if it reuses most of current codes? Since we've already used them
>>> in sleep or hibernation?
>>>
>>> Thanks
>> Except almost no one uses sleep or hybernate with VMs. I'm not saying
>> it's a bad idea, just that it needs a lot of testing before release and
>> we won't get enough if we merge at this point.
>>
> Then it would seem like a good thing to have another user of these paths and
> find the bugs versus letting them sit there for some poor folks who do use
> sleep/hybernate.
>
Yes, and uncovering hypervisor bugs now is better than uncovering it in
the future.
Thanks
^ permalink raw reply
* [PATCH net-next] r8152: fix the wrong spelling
From: Hayes Wang @ 2017-01-25 5:41 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, linux-usb, Hayes Wang
Replace rumtime with runtime.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/usb/r8152.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index f3b48ad..d59d773 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3576,7 +3576,7 @@ static bool delay_autosuspend(struct r8152 *tp)
return false;
}
-static int rtl8152_rumtime_suspend(struct r8152 *tp)
+static int rtl8152_runtime_suspend(struct r8152 *tp)
{
struct net_device *netdev = tp->netdev;
int ret = 0;
@@ -3653,7 +3653,7 @@ static int rtl8152_suspend(struct usb_interface *intf, pm_message_t message)
mutex_lock(&tp->control);
if (PMSG_IS_AUTO(message))
- ret = rtl8152_rumtime_suspend(tp);
+ ret = rtl8152_runtime_suspend(tp);
else
ret = rtl8152_system_suspend(tp);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net 1/4] r8152: avoid start_xmit to call napi_schedule during autosuspend
From: Stephen Hemminger @ 2017-01-25 5:02 UTC (permalink / raw)
To: Hayes Wang; +Cc: netdev, nic_swsd, linux-kernel, linux-usb
In-Reply-To: <1394712342-15778-237-Taiwan-albertk@realtek.com>
On Wed, 25 Jan 2017 10:50:51 +0800
Hayes Wang <hayeswang@realtek.com> wrote:
> Adjust the setting of the flag of SELECTIVE_SUSPEND to prevent start_xmit()
> from calling napi_schedule() directly during runtime suspend.
>
> After calling napi_disable() or clearing the flag of WORK_ENABLE,
> scheduling the napi is useless.
>
> Signed-off-by: Hayes Wang <hayeswang@realtek.com>
> ---
> drivers/net/usb/r8152.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
> index e1466b4..27b0b44 100644
> --- a/drivers/net/usb/r8152.c
> +++ b/drivers/net/usb/r8152.c
> @@ -3585,10 +3585,13 @@ static int rtl8152_rumtime_suspend(struct r8152 *tp)
> struct net_device *netdev = tp->netdev;
> int ret = 0;
>
> + set_bit(SELECTIVE_SUSPEND, &tp->flags);
> +
> if (netif_running(netdev) && test_bit(WORK_ENABLE, &tp->flags)) {
> u32 rcr = 0;
>
> if (delay_autosuspend(tp)) {
> + clear_bit(SELECTIVE_SUSPEND, &tp->flags);
> ret = -EBUSY;
> goto out1;
> }
> @@ -3605,6 +3608,7 @@ static int rtl8152_rumtime_suspend(struct r8152 *tp)
> if (!(ocp_data & RXFIFO_EMPTY)) {
> rxdy_gated_en(tp, false);
> ocp_write_dword(tp, MCU_TYPE_PLA, PLA_RCR, rcr);
> + clear_bit(SELECTIVE_SUSPEND, &tp->flags);
> ret = -EBUSY;
If you are going to start using bit operations then you may need smp_mb_before/after_atomic.
^ permalink raw reply
* Re: [PATCH net] tcp: correct memory barrier usage in tcp_check_space()
From: Eric Dumazet @ 2017-01-25 4:53 UTC (permalink / raw)
To: Jason Baron; +Cc: davem, netdev, Oleg Nesterov
In-Reply-To: <1485312581-13041-1-git-send-email-jbaron@akamai.com>
On Tue, 2017-01-24 at 21:49 -0500, Jason Baron wrote:
> From: Jason Baron <jbaron@akamai.com>
>
> sock_reset_flag() maps to __clear_bit() not the atomic version clear_bit().
> Thus, we need smp_mb(), smp_mb__after_atomic() is not sufficient.
>
> Fixes: 3c7151275c0c ("tcp: add memory barriers to write space paths")
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Oleg Nesterov <oleg@redhat.com>
> Signed-off-by: Jason Baron <jbaron@akamai.com>
> ---
> net/ipv4/tcp_input.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Acked-by: Eric Dumazet <edumazet@google.com>
I believe this would need also this for proper attribution.
Reported-by: Oleg Nesterov <oleg@redhat.com>
^ permalink raw reply
* Re: [PATCH v2] virtio_net: fix PAGE_SIZE > 64k
From: Alexei Starovoitov @ 2017-01-25 4:07 UTC (permalink / raw)
To: John Fastabend
Cc: Michael S. Tsirkin, David Miller, linux-kernel@vger.kernel.org,
Jason Wang, virtualization, netdev@vger.kernel.org
On Tue, Jan 24, 2017 at 7:48 PM, John Fastabend
<john.fastabend@gmail.com> wrote:
>
> It is a concern on my side. I want XDP and Linux stack to work
> reasonably well together.
btw the micro benchmarks showed that page per packet approach
that xdp took in mlx4 should be 10% slower vs normal operation
for tcp/ip stack. We thought that for our LB use case
it will be an acceptable slowdown, but turned out that overall we
got a performance boost, since xdp model simplified user space
and got data path faster, so we magically got extra free cpu
that is used for other apps on the same host and overall
perf win despite extra overhead in tcp/ip.
Not all use cases are the same and not everyone will be as lucky,
so I'd like to see performance of xdp_pass improving too, though
it turned out to be not as high priority as I initially estimated.
^ permalink raw reply
* Re: [PATCH net-next] net: ipv6: ignore null_entry on route dumps
From: David Ahern @ 2017-01-25 4:07 UTC (permalink / raw)
To: David Miller; +Cc: netdev, xiaolong.ye
In-Reply-To: <20170124.203932.616922168982477148.davem@davemloft.net>
On 1/24/17 6:39 PM, David Miller wrote:
> Although, it's troubling that we are trying to dump unfinished entries
> simply because of initialization order. It's arguable that this is
> the real thing to fix.
that's rabbit hole from which I have not found an exit
^ permalink raw reply
* linux-next: manual merge of the kselftest tree with the net-next tree
From: Stephen Rothwell @ 2017-01-25 4:03 UTC (permalink / raw)
To: Shuah Khan, David Miller, Networking
Cc: linux-next, linux-kernel, Daniel Borkmann,
bamvor.zhangjian@huawei.com, Bamvor Jian Zhang
Hi Shuah,
Today's linux-next merge of the kselftest tree got a conflict in:
tools/testing/selftests/bpf/Makefile
between commit:
62b64660262a ("bpf: add prog tag test case to bpf selftests")
from the net-next tree and commit:
88baa78d1f31 ("selftests: remove duplicated all and clean target")
from the kselftest tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc tools/testing/selftests/bpf/Makefile
index 769a6cb42b4b,058351b0694f..000000000000
--- a/tools/testing/selftests/bpf/Makefile
+++ b/tools/testing/selftests/bpf/Makefile
@@@ -1,13 -1,7 +1,7 @@@
CFLAGS += -Wall -O2 -I../../../../usr/include
- test_objs = test_verifier test_tag test_maps test_lru_map test_lpm_map
-TEST_GEN_PROGS = test_verifier test_maps test_lru_map
++TEST_GEN_PROGS = test_verifier test_tag test_maps test_lru_map test_lpm_map
- TEST_PROGS := $(test_objs) test_kmod.sh
- TEST_FILES := $(test_objs)
-
- all: $(test_objs)
+ TEST_PROGS := test_kmod.sh
include ../lib.mk
-
- clean:
- $(RM) $(test_objs)
^ permalink raw reply
* Re: [net PATCH v5 1/6] virtio_net: use dev_kfree_skb for small buffer XDP receive
From: John Fastabend @ 2017-01-25 4:02 UTC (permalink / raw)
To: Michael S. Tsirkin, Jason Wang
Cc: David Miller, john.r.fastabend, netdev, alexei.starovoitov,
daniel
In-Reply-To: <20170125051810-mutt-send-email-mst@kernel.org>
On 17-01-24 07:23 PM, Michael S. Tsirkin wrote:
> On Wed, Jan 25, 2017 at 10:57:12AM +0800, Jason Wang wrote:
>>
>>
>> On 2017年01月25日 04:08, Michael S. Tsirkin wrote:
>>> On Tue, Jan 24, 2017 at 02:43:28PM -0500, David Miller wrote:
>>>> From: "Michael S. Tsirkin" <mst@redhat.com>
>>>> Date: Mon, 23 Jan 2017 23:08:35 +0200
>>>>
>>>>> On Tue, Jan 17, 2017 at 02:19:50PM -0800, John Fastabend wrote:
>>>>>> In the small buffer case during driver unload we currently use
>>>>>> put_page instead of dev_kfree_skb. Resolve this by adding a check
>>>>>> for virtnet mode when checking XDP queue type. Also name the
>>>>>> function so that the code reads correctly to match the additional
>>>>>> check.
>>>>>>
>>>>>> Fixes: bb91accf2733 ("virtio-net: XDP support for small buffers")
>>>>>> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
>>>>>> Acked-by: Jason Wang <jasowang@redhat.com>
>>>>> Acked-by: Michael S. Tsirkin <mst@redhat.com>
>>>>>
>>>>> I think we definitely want this one in -net as it's
>>>>> a bugfix.
>>>> This whole series is a bug fix, we must have adjust_header XDP
>>>> support in the virtio_net driver before v4.10 goes out, it is
>>>> a requires base feature for XDP.
>>> I have to say device resets outside probe have a huge potential
>>> to uncover hypervisor bugs.
>>
>> Maybe not if it reuses most of current codes? Since we've already used them
>> in sleep or hibernation?
>>
>> Thanks
>
> Except almost no one uses sleep or hybernate with VMs. I'm not saying
> it's a bad idea, just that it needs a lot of testing before release and
> we won't get enough if we merge at this point.
>
Then it would seem like a good thing to have another user of these paths and
find the bugs versus letting them sit there for some poor folks who do use
sleep/hybernate.
>>> I am rather uncomfortable
>>> doing that after -rc1.
>>>
>>> How about a module option to disable it by default?
>>> We can then ship a partial implementation in 4.10
>>> and work on completing it in 4.11.
>>>
Ugh I would prefer to avoid module options. This will only happen if users
push XDP program into driver anyways.
>
> To clarify, I'm thinking an option similar to enable_xdp,
> and have all packets have a 256 byte headroom for 4.10.
An option where? In QEMU side, in driver? Is the reset really that bad, coming
from a hardware driver side lots of configuration changes can cause resets. I
agree its not overly elegant but could follow on patches be used to make it
prettier if possible.
I know folks prefer to avoid tuning knobs but I think exposing the headroom
configuration to users might not be a bad idea. After all these same users are
already programming maps and ebpf codes. A simple tuning knob should not be a
big deal and reasonable defaults would of course be used. That is a net-next
debate though.
>
> Consider our options for 4.11.
>
Finally just to point out here are the drivers with XDP support on latest
net tree,
mlx/mlx5
mlx/mlx4
qlogic/qede
netronome/nfp
virtio_net
And here is the list of adjust header support,
mlx/mlx4
So we currently have the same feature gap on all the other drivers except one.
Although I do not think that is a very good excuse. Lets figure out what we
should do about virtio.
Thanks,
John
^ permalink raw reply
* Re: [PATCH v2] virtio_net: fix PAGE_SIZE > 64k
From: John Fastabend @ 2017-01-25 3:48 UTC (permalink / raw)
To: Michael S. Tsirkin, David Miller; +Cc: netdev, linux-kernel, virtualization
In-Reply-To: <20170124235101-mutt-send-email-mst@kernel.org>
On 17-01-24 01:56 PM, Michael S. Tsirkin wrote:
> On Tue, Jan 24, 2017 at 04:10:46PM -0500, David Miller wrote:
>> This works in the regimen that XDP packets always live in exactly one
>> page. That will be needed to mmap the RX ring into userspace, and it
>> helps make adjust_header trivial as well.
I still don't see why this is a hard requirement for mmap let me post
some patches later tonight to show how we do this with af_packet.
>
> I think the point was to avoid resets across xdp attach/detach. If we
> are doing resets now, we could do whatever buffering we want. We could
> also just disable mergeable buffers for that matter.
>
>> MTU 1500, PAGESIZE >= 4096, so a headroom of 256 is no problem, and
>> we still have enough tailroom for skb_shared_info should we wrap
>> the buffer into a real SKB and push it into the stack.
>>
>> If you are trying to do buffering differently for virtio_net, well...
>> that's a self inflicted wound as far as I can tell.
>
> Right but I was wondering about the fact that this makes XDP_PASS
> much slower than processing skbs without XDP, as truesize is huge
> so we'll quickly run out of rmem space.
>
> When XDP is used to fight DOS attacks, why isn't this a concern?
>
It is a concern on my side. I want XDP and Linux stack to work
reasonably well together.
.John
^ permalink raw reply
* Re: [net PATCH v5 1/6] virtio_net: use dev_kfree_skb for small buffer XDP receive
From: Michael S. Tsirkin @ 2017-01-25 3:23 UTC (permalink / raw)
To: Jason Wang
Cc: David Miller, john.fastabend, john.r.fastabend, netdev,
alexei.starovoitov, daniel
In-Reply-To: <a129524e-c4af-5c67-5397-dec992c70fa1@redhat.com>
On Wed, Jan 25, 2017 at 10:57:12AM +0800, Jason Wang wrote:
>
>
> On 2017年01月25日 04:08, Michael S. Tsirkin wrote:
> > On Tue, Jan 24, 2017 at 02:43:28PM -0500, David Miller wrote:
> > > From: "Michael S. Tsirkin" <mst@redhat.com>
> > > Date: Mon, 23 Jan 2017 23:08:35 +0200
> > >
> > > > On Tue, Jan 17, 2017 at 02:19:50PM -0800, John Fastabend wrote:
> > > > > In the small buffer case during driver unload we currently use
> > > > > put_page instead of dev_kfree_skb. Resolve this by adding a check
> > > > > for virtnet mode when checking XDP queue type. Also name the
> > > > > function so that the code reads correctly to match the additional
> > > > > check.
> > > > >
> > > > > Fixes: bb91accf2733 ("virtio-net: XDP support for small buffers")
> > > > > Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
> > > > > Acked-by: Jason Wang <jasowang@redhat.com>
> > > > Acked-by: Michael S. Tsirkin <mst@redhat.com>
> > > >
> > > > I think we definitely want this one in -net as it's
> > > > a bugfix.
> > > This whole series is a bug fix, we must have adjust_header XDP
> > > support in the virtio_net driver before v4.10 goes out, it is
> > > a requires base feature for XDP.
> > I have to say device resets outside probe have a huge potential
> > to uncover hypervisor bugs.
>
> Maybe not if it reuses most of current codes? Since we've already used them
> in sleep or hibernation?
>
> Thanks
Except almost no one uses sleep or hybernate with VMs. I'm not saying
it's a bad idea, just that it needs a lot of testing before release and
we won't get enough if we merge at this point.
> > I am rather uncomfortable
> > doing that after -rc1.
> >
> > How about a module option to disable it by default?
> > We can then ship a partial implementation in 4.10
> > and work on completing it in 4.11.
> >
To clarify, I'm thinking an option similar to enable_xdp,
and have all packets have a 256 byte headroom for 4.10.
Consider our options for 4.11.
--
MST
^ permalink raw reply
* Re: XDP offload to hypervisor
From: Michael S. Tsirkin @ 2017-01-25 3:17 UTC (permalink / raw)
To: Jason Wang
Cc: John Fastabend, john.r.fastabend, netdev, alexei.starovoitov,
daniel
In-Reply-To: <7b09fb3f-34bc-23d2-563f-79f28e5aec44@redhat.com>
On Wed, Jan 25, 2017 at 10:45:18AM +0800, Jason Wang wrote:
>
>
> On 2017年01月24日 05:56, John Fastabend wrote:
> > On 17-01-23 01:40 PM, Michael S. Tsirkin wrote:
> > > I've been thinking about passing XDP programs from guest to the
> > > hypervisor. Basically, after getting an incoming packet, we could run
> > > an XDP program in host kernel.
> > >
> > Interesting. I am planning on adding XDP to tun driver. My use case
> > is we want to use XDP to restrict VM traffic. I was planning on pushing
> > the xdp program execution into tun_get_user(). So different then "offloading"
> > an xdp program into hypervisor.
>
> This looks interesting to me. BTW, I was playing a patch and tries to make
> use of XDP to accelerate macvtap in passthrough mode rx on host. With the
> patch, XDP buffer instead of sbk could be used for vhost rx, and tests shows
> nice results.
>
> But this seems conflict with XDP offload idea here.
>
> Thanks
One way is to add ability to attach two XDP
programs to macvtap: guest and host. Run host first on XDP_PASS
run guest.
> >
> > > If the result is XDP_DROP or XDP_TX we don't need to wake up the guest at all!
> > >
> > nice win.
> >
> > > When using tun for networking - especially with adjust_head - this
> > > unfortunately probably means we need to do a data copy unless there is
> > > enough headroom. How much is enough though?
> > We were looking at making headroom configurable on Intel drivers or at
> > least matching it with XDP headroom guidelines. (although the developers
> > had the same complaint about 256B being large). Then at least on supported
> > drivers the copy could be an exception path.
> >
> > > Another issue is around host/guest ABI. Guest BPF could add new features
> > > at any point. What if hypervisor can not support it all? I guess we
> > > could try loading program into hypervisor and run it within guest on
> > > failure to load, but this ignores question of cross-version
> > > compatibility - someone might start guest on a new host
> > > then try to move to an old one. So we will need an option
> > > "behave like an older host" such that guest can start and then
> > > move to an older host later. This will likely mean
> > > implementing this validation of programs in qemu userspace unless linux
> > > can supply something like this. Is this (disabling some features)
> > > something that might be of interest to larger bpf community?
> > This is interesting to me at least. Another interesting "feature" of
> > running bpf in qemu userspace is it could work with vhost_user as well
> > presumably?
> >
> > > With a device such as macvtap there exist configurations where a single
> > > guest is in control of the device (aka passthrough mode) in that case
> > > there's a potential to run xdp on host before host skb is built, unless
> > > host already has an xdp program attached. If it does we could run the
> > > program within guest, but what if a guest program got attached first?
> > > Maybe we should pass a flag in the packet "xdp passed on this packet in
> > > host". Then, guest can skip running it. Unless we do a full reset
> > > there's always a potential for packets to slip through, e.g. on xdp
> > > program changes. Maybe a flush command is needed, or force queue or
> > > device reset to make sure nothing is going on. Does this make sense?
> > >
> > Could the virtio driver pretend its "offloading" the XDP program to
> > hardware? This would make it explicit in VM that the program is run
> > before data is received by virtio_net. Then qemu is enabling the
> > offload framework which would be interesting.
> >
> > > Thanks!
> > >
^ permalink raw reply
* Re: XDP offload to hypervisor
From: Michael S. Tsirkin @ 2017-01-25 3:12 UTC (permalink / raw)
To: Jason Wang
Cc: John Fastabend, john.r.fastabend, netdev, alexei.starovoitov,
daniel
In-Reply-To: <454ebe0d-2fdb-6380-7345-7913b04353d0@redhat.com>
On Wed, Jan 25, 2017 at 10:41:24AM +0800, Jason Wang wrote:
>
>
> On 2017年01月24日 05:40, Michael S. Tsirkin wrote:
> > I've been thinking about passing XDP programs from guest to the
> > hypervisor. Basically, after getting an incoming packet, we could run
> > an XDP program in host kernel.
> >
> > If the result is XDP_DROP or XDP_TX we don't need to wake up the guest at all!
>
> Interesting, but there're some questions:
>
> - This may work well for XDP_DROP and XDP_TX, and manage to work for
> XDP_PASS. But what if XDP were extend for other capabilities in the future?
> E.g forward to other interface or userspace?
This is exactly what I am saying. Any future extensions will need
feature negotiation.
> - For XDP_DROP, it can be done through socket filter.
> - Need to translate XDP_TX as something like XDP_RX at least for tun. Or it
> may bring some confusion if tun support XDP or XDP were supported in tx
> patch in the future.
>
> >
> > When using tun for networking - especially with adjust_head - this
> > unfortunately probably means we need to do a data copy unless there is
> > enough headroom. How much is enough though?
>
> Not a tun specific issue I believe?
It is tun specific because tun gets skbs from linux net core while XDP
expects pre-skb pages.
> >
> > Another issue is around host/guest ABI. Guest BPF could add new features
> > at any point. What if hypervisor can not support it all? I guess we
> > could try loading program into hypervisor and run it within guest on
> > failure to load, but this ignores question of cross-version
> > compatibility - someone might start guest on a new host
> > then try to move to an old one. So we will need an option
> > "behave like an older host" such that guest can start and then
> > move to an older host later.
>
> I'm suspect whether or not this can be done easily.
>
> > This will likely mean
> > implementing this validation of programs in qemu userspace unless linux
> > can supply something like this. Is this (disabling some features)
> > something that might be of interest to larger bpf community?
> >
> > With a device such as macvtap there exist configurations where a single
> > guest is in control of the device (aka passthrough mode) in that case
> > there's a potential to run xdp on host before host skb is built, unless
> > host already has an xdp program attached. If it does we could run the
> > program within guest, but what if a guest program got attached first?
> > Maybe we should pass a flag in the packet "xdp passed on this packet in
> > host". Then, guest can skip running it. Unless we do a full reset
> > there's always a potential for packets to slip through, e.g. on xdp
> > program changes. Maybe a flush command is needed, or force queue or
> > device reset to make sure nothing is going on. Does this make sense?
> >
> > Thanks!
> >
^ permalink raw reply
* Re: XDP offload to hypervisor
From: Jason Wang @ 2017-01-25 3:03 UTC (permalink / raw)
To: Alexei Starovoitov, Michael S. Tsirkin
Cc: John Fastabend, john.r.fastabend, netdev, daniel
In-Reply-To: <20170124010201.GB60699@ast-mbp.thefacebook.com>
On 2017年01月24日 09:02, Alexei Starovoitov wrote:
> Frankly I don't understand the whole virtio nit picking that was happening.
> imo virtio+xdp by itself is only useful for debugging, development and testing
> of xdp programs in a VM. The discussion about performance of virtio+xdp
> will only be meaningful when corresponding host part is done.
Maybe not, consider you may have dpdk backend on host.
Thanks
^ permalink raw reply
* Re: [net PATCH v5 1/6] virtio_net: use dev_kfree_skb for small buffer XDP receive
From: Jason Wang @ 2017-01-25 2:57 UTC (permalink / raw)
To: Michael S. Tsirkin, David Miller
Cc: john.fastabend, john.r.fastabend, netdev, alexei.starovoitov,
daniel
In-Reply-To: <20170124215412-mutt-send-email-mst@kernel.org>
On 2017年01月25日 04:08, Michael S. Tsirkin wrote:
> On Tue, Jan 24, 2017 at 02:43:28PM -0500, David Miller wrote:
>> From: "Michael S. Tsirkin" <mst@redhat.com>
>> Date: Mon, 23 Jan 2017 23:08:35 +0200
>>
>>> On Tue, Jan 17, 2017 at 02:19:50PM -0800, John Fastabend wrote:
>>>> In the small buffer case during driver unload we currently use
>>>> put_page instead of dev_kfree_skb. Resolve this by adding a check
>>>> for virtnet mode when checking XDP queue type. Also name the
>>>> function so that the code reads correctly to match the additional
>>>> check.
>>>>
>>>> Fixes: bb91accf2733 ("virtio-net: XDP support for small buffers")
>>>> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
>>>> Acked-by: Jason Wang <jasowang@redhat.com>
>>> Acked-by: Michael S. Tsirkin <mst@redhat.com>
>>>
>>> I think we definitely want this one in -net as it's
>>> a bugfix.
>> This whole series is a bug fix, we must have adjust_header XDP
>> support in the virtio_net driver before v4.10 goes out, it is
>> a requires base feature for XDP.
> I have to say device resets outside probe have a huge potential
> to uncover hypervisor bugs.
Maybe not if it reuses most of current codes? Since we've already used
them in sleep or hibernation?
Thanks
> I am rather uncomfortable
> doing that after -rc1.
>
> How about a module option to disable it by default?
> We can then ship a partial implementation in 4.10
> and work on completing it in 4.11.
>
^ permalink raw reply
* [PATCH net] tcp: correct memory barrier usage in tcp_check_space()
From: Jason Baron @ 2017-01-25 2:49 UTC (permalink / raw)
To: davem; +Cc: netdev, Eric Dumazet, Oleg Nesterov
From: Jason Baron <jbaron@akamai.com>
sock_reset_flag() maps to __clear_bit() not the atomic version clear_bit().
Thus, we need smp_mb(), smp_mb__after_atomic() is not sufficient.
Fixes: 3c7151275c0c ("tcp: add memory barriers to write space paths")
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Jason Baron <jbaron@akamai.com>
---
net/ipv4/tcp_input.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index bfa165cc455a..1e22ae4a5b38 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -5028,7 +5028,7 @@ static void tcp_check_space(struct sock *sk)
if (sock_flag(sk, SOCK_QUEUE_SHRUNK)) {
sock_reset_flag(sk, SOCK_QUEUE_SHRUNK);
/* pairs with tcp_poll() */
- smp_mb__after_atomic();
+ smp_mb();
if (sk->sk_socket &&
test_bit(SOCK_NOSPACE, &sk->sk_socket->flags)) {
tcp_new_space(sk);
--
2.6.1
^ permalink raw reply related
* Re: XDP offload to hypervisor
From: Jason Wang @ 2017-01-25 2:51 UTC (permalink / raw)
To: Alexei Starovoitov, Michael S. Tsirkin
Cc: John Fastabend, john.r.fastabend, netdev, daniel
In-Reply-To: <20170124010201.GB60699@ast-mbp.thefacebook.com>
On 2017年01月24日 09:02, Alexei Starovoitov wrote:
> On Mon, Jan 23, 2017 at 11:40:29PM +0200, Michael S. Tsirkin wrote:
>> I've been thinking about passing XDP programs from guest to the
>> hypervisor. Basically, after getting an incoming packet, we could run
>> an XDP program in host kernel.
>>
>> If the result is XDP_DROP or XDP_TX we don't need to wake up the guest at all!
> that's an interesting idea!
> Long term 'xdp offload' needs to be defined, since NICs become smarter
> and can accelerate xdp programs.
> So pushing the xdp program down from virtio in the guest into host
> and from x86 into nic cpu should probably be handled through the same api.
>
>> When using tun for networking - especially with adjust_head - this
>> unfortunately probably means we need to do a data copy unless there is
>> enough headroom. How much is enough though?
> Frankly I don't understand the whole virtio nit picking that was happening.
> imo virtio+xdp by itself is only useful for debugging, development and testing
> of xdp programs in a VM. The discussion about performance of virtio+xdp
> will only be meaningful when corresponding host part is done.
I was doing a prototype to make XDP rx works for macvtap (with minor
changes in the driver e.g mlx4). Tests shows improvements, plan to post
as RFC after spring festival holiday in China. This is even useful for
nested VM but can not work well for XDP offload.
> Likely in the form of vhost extensions and may be driver changes.
> Trying to optimize virtio+xdp when host is doing traditional skb+vhost
> isn't going to be impactful.
> But when host can do xdp in phyiscal NIC that can deliver raw
> pages into vhost that gets picked up by guest virtio, then we hopefully
> will be around 10G line rate. page pool is likely needed in such scenario.
> Some new xdp action like xdp_tx_into_vhost or whatever.
Yes, in my prototype, mlx4 XDP rx page pool were reused.
Thanks
> And guest will be seeing full pages that host nic provided and discussion
> about headroom will be automatically solved.
> Arguing that skb has 64-byte headroom and therefore we need to
> reduce XDP_PACKET_HEADROOM is really upside down.
>
>> Another issue is around host/guest ABI. Guest BPF could add new features
>> at any point. What if hypervisor can not support it all? I guess we
>> could try loading program into hypervisor and run it within guest on
>> failure to load, but this ignores question of cross-version
>> compatibility - someone might start guest on a new host
>> then try to move to an old one. So we will need an option
>> "behave like an older host" such that guest can start and then
>> move to an older host later. This will likely mean
>> implementing this validation of programs in qemu userspace unless linux
>> can supply something like this. Is this (disabling some features)
>> something that might be of interest to larger bpf community?
> In case of x86->nic offload not all xdp features will be supported
> by the nic and that is expected. The user will request 'offload of xdp prog'
> in some form and if it cannot be done, then xdp programs will run
> on x86 as before. Same thing, I imagine, is applicable to virtio->host
> offload. Therefore I don't see a need for user space visible
> feature negotiation.
>
>> With a device such as macvtap there exist configurations where a single
>> guest is in control of the device (aka passthrough mode) in that case
>> there's a potential to run xdp on host before host skb is built, unless
>> host already has an xdp program attached. If it does we could run the
>> program within guest, but what if a guest program got attached first?
>> Maybe we should pass a flag in the packet "xdp passed on this packet in
>> host". Then, guest can skip running it. Unless we do a full reset
>> there's always a potential for packets to slip through, e.g. on xdp
>> program changes. Maybe a flush command is needed, or force queue or
>> device reset to make sure nothing is going on. Does this make sense?
> All valid questions and concerns.
> Since there is still no xdp_adjust_head support in virtio,
> it feels kinda early to get into detailed 'virtio offload' discussion.
>
^ permalink raw reply
* [PATCH net 4/4] r8152: check rx after napi is enabled
From: Hayes Wang @ 2017-01-25 2:50 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, linux-usb, Hayes Wang
In-Reply-To: <1394712342-15778-236-Taiwan-albertk@realtek.com>
Schedule the napi after napi_enable() for rx, if it is necessary.
If the rx is completed when napi is disabled, the sheduling of napi
would be lost. Then, no one handles the rx packet until next napi
is scheduled.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/usb/r8152.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index f65109b..f0f55b3 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -32,7 +32,7 @@
#define NETNEXT_VERSION "08"
/* Information for net */
-#define NET_VERSION "7"
+#define NET_VERSION "8"
#define DRIVER_VERSION "v1." NETNEXT_VERSION "." NET_VERSION
#define DRIVER_AUTHOR "Realtek linux nic maintainers <nic_swsd@realtek.com>"
@@ -3561,6 +3561,9 @@ static int rtl8152_post_reset(struct usb_interface *intf)
netif_wake_queue(netdev);
usb_submit_urb(tp->intr_urb, GFP_KERNEL);
+ if (!list_empty(&tp->rx_done))
+ napi_schedule(&tp->napi);
+
return 0;
}
@@ -3696,6 +3699,8 @@ static int rtl8152_resume(struct usb_interface *intf)
rtl_start_rx(tp);
napi_enable(&tp->napi);
clear_bit(SELECTIVE_SUSPEND, &tp->flags);
+ if (!list_empty(&tp->rx_done))
+ napi_schedule(&tp->napi);
} else {
tp->rtl_ops.up(tp);
netif_carrier_off(tp->netdev);
--
2.7.4
^ permalink raw reply related
* [PATCH net 3/4] r8152: re-schedule napi for tx
From: Hayes Wang @ 2017-01-25 2:50 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, linux-usb, Hayes Wang
In-Reply-To: <1394712342-15778-236-Taiwan-albertk@realtek.com>
Re-schedule napi after napi_complete() for tx, if it is necessay.
In r8152_poll(), if the tx is completed after tx_bottom() and before
napi_complete(), the scheduling of napi would be lost. Then, no
one handles the next tx until the next napi_schedule() is called.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/usb/r8152.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 3454238..f65109b 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1936,6 +1936,9 @@ static int r8152_poll(struct napi_struct *napi, int budget)
napi_complete(napi);
if (!list_empty(&tp->rx_done))
napi_schedule(napi);
+ else if (!skb_queue_empty(&tp->tx_queue) &&
+ !list_empty(&tp->tx_free))
+ napi_schedule(&tp->napi);
}
return work_done;
--
2.7.4
^ permalink raw reply related
* [PATCH net 2/4] r8152: avoid start_xmit to schedule napi when napi is disabled
From: Hayes Wang @ 2017-01-25 2:50 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: nic_swsd-Rasf1IRRPZFBDgjK7y7TUQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Hayes Wang
In-Reply-To: <1394712342-15778-236-Taiwan-albertk-Rasf1IRRPZFBDgjK7y7TUQ@public.gmane.org>
Stop the tx when the napi is disabled to prevent napi_schedule() is
called.
Signed-off-by: Hayes Wang <hayeswang-Rasf1IRRPZFBDgjK7y7TUQ@public.gmane.org>
---
drivers/net/usb/r8152.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 27b0b44..3454238 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3155,10 +3155,13 @@ static void set_carrier(struct r8152 *tp)
if (!netif_carrier_ok(netdev)) {
tp->rtl_ops.enable(tp);
set_bit(RTL8152_SET_RX_MODE, &tp->flags);
+ netif_stop_queue(netdev);
napi_disable(&tp->napi);
netif_carrier_on(netdev);
rtl_start_rx(tp);
napi_enable(&tp->napi);
+ netif_wake_queue(netdev);
+ netif_info(tp, link, netdev, "carrier on\n");
}
} else {
if (netif_carrier_ok(netdev)) {
@@ -3166,6 +3169,7 @@ static void set_carrier(struct r8152 *tp)
napi_disable(&tp->napi);
tp->rtl_ops.disable(tp);
napi_enable(&tp->napi);
+ netif_info(tp, link, netdev, "carrier off\n");
}
}
}
@@ -3515,12 +3519,12 @@ static int rtl8152_pre_reset(struct usb_interface *intf)
if (!netif_running(netdev))
return 0;
+ netif_stop_queue(netdev);
napi_disable(&tp->napi);
clear_bit(WORK_ENABLE, &tp->flags);
usb_kill_urb(tp->intr_urb);
cancel_delayed_work_sync(&tp->schedule);
if (netif_carrier_ok(netdev)) {
- netif_stop_queue(netdev);
mutex_lock(&tp->control);
tp->rtl_ops.disable(tp);
mutex_unlock(&tp->control);
@@ -3548,10 +3552,10 @@ static int rtl8152_post_reset(struct usb_interface *intf)
rtl_start_rx(tp);
rtl8152_set_rx_mode(netdev);
mutex_unlock(&tp->control);
- netif_wake_queue(netdev);
}
napi_enable(&tp->napi);
+ netif_wake_queue(netdev);
usb_submit_urb(tp->intr_urb, GFP_KERNEL);
return 0;
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH net 1/4] r8152: avoid start_xmit to call napi_schedule during autosuspend
From: Hayes Wang @ 2017-01-25 2:50 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, linux-usb, Hayes Wang
In-Reply-To: <1394712342-15778-236-Taiwan-albertk@realtek.com>
Adjust the setting of the flag of SELECTIVE_SUSPEND to prevent start_xmit()
from calling napi_schedule() directly during runtime suspend.
After calling napi_disable() or clearing the flag of WORK_ENABLE,
scheduling the napi is useless.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/usb/r8152.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index e1466b4..27b0b44 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3585,10 +3585,13 @@ static int rtl8152_rumtime_suspend(struct r8152 *tp)
struct net_device *netdev = tp->netdev;
int ret = 0;
+ set_bit(SELECTIVE_SUSPEND, &tp->flags);
+
if (netif_running(netdev) && test_bit(WORK_ENABLE, &tp->flags)) {
u32 rcr = 0;
if (delay_autosuspend(tp)) {
+ clear_bit(SELECTIVE_SUSPEND, &tp->flags);
ret = -EBUSY;
goto out1;
}
@@ -3605,6 +3608,7 @@ static int rtl8152_rumtime_suspend(struct r8152 *tp)
if (!(ocp_data & RXFIFO_EMPTY)) {
rxdy_gated_en(tp, false);
ocp_write_dword(tp, MCU_TYPE_PLA, PLA_RCR, rcr);
+ clear_bit(SELECTIVE_SUSPEND, &tp->flags);
ret = -EBUSY;
goto out1;
}
@@ -3624,8 +3628,6 @@ static int rtl8152_rumtime_suspend(struct r8152 *tp)
}
}
- set_bit(SELECTIVE_SUSPEND, &tp->flags);
-
out1:
return ret;
}
@@ -3681,12 +3683,12 @@ static int rtl8152_resume(struct usb_interface *intf)
if (netif_running(tp->netdev) && tp->netdev->flags & IFF_UP) {
if (test_bit(SELECTIVE_SUSPEND, &tp->flags)) {
tp->rtl_ops.autosuspend_en(tp, false);
- clear_bit(SELECTIVE_SUSPEND, &tp->flags);
napi_disable(&tp->napi);
set_bit(WORK_ENABLE, &tp->flags);
if (netif_carrier_ok(tp->netdev))
rtl_start_rx(tp);
napi_enable(&tp->napi);
+ clear_bit(SELECTIVE_SUSPEND, &tp->flags);
} else {
tp->rtl_ops.up(tp);
netif_carrier_off(tp->netdev);
--
2.7.4
^ permalink raw reply related
* [PATCH net 0/4] r8152: fix scheduling napi
From: Hayes Wang @ 2017-01-25 2:50 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, linux-usb, Hayes Wang
Scheduling the napi during the following periods would let it be ignored.
And the events wouldn't be handled until next napi_schedule() is called.
1. after napi_disable and before napi_enable().
2. after all actions of napi function is completed and before calling
napi_complete().
If no next napi_schedule() is called, tx or rx would stop working.
In order to avoid these situations, the followings solutions are applied.
1. prevent start_xmit() from calling napi_schedule() during runtime suspend
or after napi_disable().
2. re-schedule the napi for tx if it is necessary.
3. check if any rx is finished or not after napi_enable().
Hayes Wang (4):
r8152: avoid start_xmit to call napi_schedule during autosuspend
r8152: avoid start_xmit to schedule napi when napi is disabled
r8152: re-schedule napi for tx
r8152: check rx after napi is enabled
drivers/net/usb/r8152.c | 26 ++++++++++++++++++++------
1 file changed, 20 insertions(+), 6 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: XDP offload to hypervisor
From: Jason Wang @ 2017-01-25 2:45 UTC (permalink / raw)
To: John Fastabend, Michael S. Tsirkin
Cc: john.r.fastabend, netdev, alexei.starovoitov, daniel
In-Reply-To: <58867C00.1060901@gmail.com>
On 2017年01月24日 05:56, John Fastabend wrote:
> On 17-01-23 01:40 PM, Michael S. Tsirkin wrote:
>> I've been thinking about passing XDP programs from guest to the
>> hypervisor. Basically, after getting an incoming packet, we could run
>> an XDP program in host kernel.
>>
> Interesting. I am planning on adding XDP to tun driver. My use case
> is we want to use XDP to restrict VM traffic. I was planning on pushing
> the xdp program execution into tun_get_user(). So different then "offloading"
> an xdp program into hypervisor.
This looks interesting to me. BTW, I was playing a patch and tries to
make use of XDP to accelerate macvtap in passthrough mode rx on host.
With the patch, XDP buffer instead of sbk could be used for vhost rx,
and tests shows nice results.
But this seems conflict with XDP offload idea here.
Thanks
>
>> If the result is XDP_DROP or XDP_TX we don't need to wake up the guest at all!
>>
> nice win.
>
>> When using tun for networking - especially with adjust_head - this
>> unfortunately probably means we need to do a data copy unless there is
>> enough headroom. How much is enough though?
> We were looking at making headroom configurable on Intel drivers or at
> least matching it with XDP headroom guidelines. (although the developers
> had the same complaint about 256B being large). Then at least on supported
> drivers the copy could be an exception path.
>
>> Another issue is around host/guest ABI. Guest BPF could add new features
>> at any point. What if hypervisor can not support it all? I guess we
>> could try loading program into hypervisor and run it within guest on
>> failure to load, but this ignores question of cross-version
>> compatibility - someone might start guest on a new host
>> then try to move to an old one. So we will need an option
>> "behave like an older host" such that guest can start and then
>> move to an older host later. This will likely mean
>> implementing this validation of programs in qemu userspace unless linux
>> can supply something like this. Is this (disabling some features)
>> something that might be of interest to larger bpf community?
> This is interesting to me at least. Another interesting "feature" of
> running bpf in qemu userspace is it could work with vhost_user as well
> presumably?
>
>> With a device such as macvtap there exist configurations where a single
>> guest is in control of the device (aka passthrough mode) in that case
>> there's a potential to run xdp on host before host skb is built, unless
>> host already has an xdp program attached. If it does we could run the
>> program within guest, but what if a guest program got attached first?
>> Maybe we should pass a flag in the packet "xdp passed on this packet in
>> host". Then, guest can skip running it. Unless we do a full reset
>> there's always a potential for packets to slip through, e.g. on xdp
>> program changes. Maybe a flush command is needed, or force queue or
>> device reset to make sure nothing is going on. Does this make sense?
>>
> Could the virtio driver pretend its "offloading" the XDP program to
> hardware? This would make it explicit in VM that the program is run
> before data is received by virtio_net. Then qemu is enabling the
> offload framework which would be interesting.
>
>> Thanks!
>>
^ permalink raw reply
* Re: XDP offload to hypervisor
From: Jason Wang @ 2017-01-25 2:41 UTC (permalink / raw)
To: Michael S. Tsirkin, John Fastabend
Cc: john.r.fastabend, netdev, alexei.starovoitov, daniel
In-Reply-To: <20170123230727-mutt-send-email-mst@kernel.org>
On 2017年01月24日 05:40, Michael S. Tsirkin wrote:
> I've been thinking about passing XDP programs from guest to the
> hypervisor. Basically, after getting an incoming packet, we could run
> an XDP program in host kernel.
>
> If the result is XDP_DROP or XDP_TX we don't need to wake up the guest at all!
Interesting, but there're some questions:
- This may work well for XDP_DROP and XDP_TX, and manage to work for
XDP_PASS. But what if XDP were extend for other capabilities in the
future? E.g forward to other interface or userspace?
- For XDP_DROP, it can be done through socket filter.
- Need to translate XDP_TX as something like XDP_RX at least for tun. Or
it may bring some confusion if tun support XDP or XDP were supported in
tx patch in the future.
>
> When using tun for networking - especially with adjust_head - this
> unfortunately probably means we need to do a data copy unless there is
> enough headroom. How much is enough though?
Not a tun specific issue I believe?
>
> Another issue is around host/guest ABI. Guest BPF could add new features
> at any point. What if hypervisor can not support it all? I guess we
> could try loading program into hypervisor and run it within guest on
> failure to load, but this ignores question of cross-version
> compatibility - someone might start guest on a new host
> then try to move to an old one. So we will need an option
> "behave like an older host" such that guest can start and then
> move to an older host later.
I'm suspect whether or not this can be done easily.
> This will likely mean
> implementing this validation of programs in qemu userspace unless linux
> can supply something like this. Is this (disabling some features)
> something that might be of interest to larger bpf community?
>
> With a device such as macvtap there exist configurations where a single
> guest is in control of the device (aka passthrough mode) in that case
> there's a potential to run xdp on host before host skb is built, unless
> host already has an xdp program attached. If it does we could run the
> program within guest, but what if a guest program got attached first?
> Maybe we should pass a flag in the packet "xdp passed on this packet in
> host". Then, guest can skip running it. Unless we do a full reset
> there's always a potential for packets to slip through, e.g. on xdp
> program changes. Maybe a flush command is needed, or force queue or
> device reset to make sure nothing is going on. Does this make sense?
>
> Thanks!
>
^ permalink raw reply
* Re: [PATCHv2 perf/core 5/7] tools lib bpf: Add bpf_program__pin()
From: Wangnan (F) @ 2017-01-25 2:18 UTC (permalink / raw)
To: Joe Stringer; +Cc: Arnaldo Carvalho de Melo, ast, Daniel Borkmann, LKML, netdev
In-Reply-To: <CAPWQB7EWFE6DToMwTws6rUpnO49UYV1Rq-=0KV2ZioUf+dTjpg@mail.gmail.com>
On 2017/1/25 9:16, Joe Stringer wrote:
> On 24 January 2017 at 17:06, Wangnan (F) <wangnan0@huawei.com> wrote:
>>
>> On 2017/1/25 9:04, Wangnan (F) wrote:
>>>
>>>
>>> On 2017/1/23 9:11, Joe Stringer wrote:
>>>> Add a new API to pin a BPF program to the filesystem. The user can
>>>> specify the path full path within a BPF filesystem to pin the program.
>>>> Programs with multiple instances are pinned as 'foo', 'foo_1', 'foo_2',
>>>> and so on.
>>>>
>>>> Signed-off-by: Joe Stringer <joe@ovn.org>
>>>> ---
>>>> v2: Don't automount BPF filesystem
>>>> Split program, map, object pinning into separate APIs and separate
>>>> patches.
>>>> ---
>>
>> [SNIP]
>>
>>>> +int bpf_program__pin(struct bpf_program *prog, const char *path)
>>>
>>> In your next patch please let caller select one instance:
>>>
>>> int bpf_program__pin(struct bpf_program *prog, int instance, const char
>>> *path)
>>> (please choose a better name)
>>>
>>> Then your can wrap it with another function to pin all instances,
>>> implement
>>> naming schema (%s_%d) there.
>>>
>>> Then implement naming schema in bpf_object__pin like:
>>>
>>> %s/objectname_mapname
>>> %s/objectname_progname_%d
>>>
>> Is it possible to use directory tree instead?
>>
>> %s/object/mapname
>> %s/object/prog/instance
> I don't think objects have names, so let's assume an object with two
> program instances named foo, and one map named bar.
>
> A call of bpf_object__pin(obj, "/sys/fs/bpf/myobj") would mount with
> the following files and directories:
> /sys/fs/bpf/myobj/foo/1
> /sys/fs/bpf/myobj/foo/2
> /sys/fs/bpf/myobj/bar
>
> Alternatively, if you want to control exactly where you want the
> progs/maps to be pinned, you can call eg
> bpf_program__pin_instance(prog, "/sys/fs/bpf/wherever", 0) and that
> instance will be mounted to /sys/fs/bpf/wherever, or alternatively
> bpf_program__pin(prog, "/sys/fs/bpf/foo"), and you will end up with
> /sys/fs/bpf/foo/{0,1}.
>
> This looks pretty reasonable to me.
It looks good to me.
Thank you.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox