* Re: [PATCH net-next 0/3] support changing steering policies in tuntap
From: Jason Wang @ 2017-09-28 7:23 UTC (permalink / raw)
To: Willem de Bruijn, Michael S. Tsirkin; +Cc: Network Development, LKML
In-Reply-To: <CAF=yD-J8hERZdwq8FJ2rtnCnZ2b7s=CAVLtPk4CS7e=RQH3sLQ@mail.gmail.com>
On 2017年09月28日 07:25, Willem de Bruijn wrote:
>>> In the future, both simple and sophisticated policy like RSS or other guest
>>> driven steering policies could be done on top.
>> IMHO there should be a more practical example before adding all this
>> indirection. And it would be nice to understand why this queue selection
>> needs to be tun specific.
> I was thinking the same and this reminds me of the various strategies
> implemented in packet fanout. tun_cpu_select_queue is analogous to
> fanout_demux_cpu though it is tun-specific in that it requires tun->numqueues.
Right, the main idea is to introduce a way to change flow steering
policy for tun. I think fanout policy could be implemented through the
API introduced in this series. (Current flow caches based automatic
steering method is tun specific).
>
> Fanout accrued various strategies until it gained an eBPF variant. Just
> supporting BPF is probably sufficient here, too.
Technically yes, but for tun, it also serve for virt. We probably still
need some hard coded policy which could be changed by guest until we can
accept an BPF program from guest I think?
Thanks
^ permalink raw reply
* Re: [PATCH net-next RFC 3/5] vhost: introduce vhost_add_used_idx()
From: Jason Wang @ 2017-09-28 7:19 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: virtualization, netdev, linux-kernel, kvm
In-Reply-To: <20170928015749-mutt-send-email-mst@kernel.org>
On 2017年09月28日 06:58, Michael S. Tsirkin wrote:
> On Wed, Sep 27, 2017 at 08:38:24AM +0800, Jason Wang wrote:
>> On 2017年09月27日 03:13, Michael S. Tsirkin wrote:
>>> On Fri, Sep 22, 2017 at 04:02:33PM +0800, Jason Wang wrote:
>>>> This patch introduces a helper which just increase the used idx. This
>>>> will be used in pair with vhost_prefetch_desc_indices() by batching
>>>> code.
>>>>
>>>> Signed-off-by: Jason Wang<jasowang@redhat.com>
>>>> ---
>>>> drivers/vhost/vhost.c | 33 +++++++++++++++++++++++++++++++++
>>>> drivers/vhost/vhost.h | 1 +
>>>> 2 files changed, 34 insertions(+)
>>>>
>>>> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
>>>> index 8424166d..6532cda 100644
>>>> --- a/drivers/vhost/vhost.c
>>>> +++ b/drivers/vhost/vhost.c
>>>> @@ -2178,6 +2178,39 @@ int vhost_add_used(struct vhost_virtqueue *vq, unsigned int head, int len)
>>>> }
>>>> EXPORT_SYMBOL_GPL(vhost_add_used);
>>>> +int vhost_add_used_idx(struct vhost_virtqueue *vq, int n)
>>>> +{
>>>> + u16 old, new;
>>>> +
>>>> + old = vq->last_used_idx;
>>>> + new = (vq->last_used_idx += n);
>>>> + /* If the driver never bothers to signal in a very long while,
>>>> + * used index might wrap around. If that happens, invalidate
>>>> + * signalled_used index we stored. TODO: make sure driver
>>>> + * signals at least once in 2^16 and remove this.
>>>> + */
>>>> + if (unlikely((u16)(new - vq->signalled_used) < (u16)(new - old)))
>>>> + vq->signalled_used_valid = false;
>>>> +
>>>> + /* Make sure buffer is written before we update index. */
>>>> + smp_wmb();
>>>> + if (vhost_put_user(vq, cpu_to_vhost16(vq, vq->last_used_idx),
>>>> + &vq->used->idx)) {
>>>> + vq_err(vq, "Failed to increment used idx");
>>>> + return -EFAULT;
>>>> + }
>>>> + if (unlikely(vq->log_used)) {
>>>> + /* Log used index update. */
>>>> + log_write(vq->log_base,
>>>> + vq->log_addr + offsetof(struct vring_used, idx),
>>>> + sizeof(vq->used->idx));
>>>> + if (vq->log_ctx)
>>>> + eventfd_signal(vq->log_ctx, 1);
>>>> + }
>>>> + return 0;
>>>> +}
>>>> +EXPORT_SYMBOL_GPL(vhost_add_used_idx);
>>>> +
>>>> static int __vhost_add_used_n(struct vhost_virtqueue *vq,
>>>> struct vring_used_elem *heads,
>>>> unsigned count)
>>>> diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
>>>> index 16c2cb6..5dd6c05 100644
>>>> --- a/drivers/vhost/vhost.h
>>>> +++ b/drivers/vhost/vhost.h
>>>> @@ -199,6 +199,7 @@ int __vhost_get_vq_desc(struct vhost_virtqueue *vq,
>>>> void vhost_discard_vq_desc(struct vhost_virtqueue *, int n);
>>>> int vhost_vq_init_access(struct vhost_virtqueue *);
>>>> +int vhost_add_used_idx(struct vhost_virtqueue *vq, int n);
>>>> int vhost_add_used(struct vhost_virtqueue *, unsigned int head, int len);
>>>> int vhost_add_used_n(struct vhost_virtqueue *, struct vring_used_elem *heads,
>>>> unsigned count);
>>> Please change the API to hide the fact that there's an index that needs
>>> to be updated.
>> In fact, an interesting optimization on top is just call
>> vhost_add_used_idx(vq, n) instead of n vhost_add_used_idx(vq, 1). That's the
>> reason I leave n in the API.
>>
>> Thanks
> Right but you could increment some internal counter in the vq
> structure then update the used index using some api
> with a generic name, e.g. add_used_complete or something like this.
>
Right, I see.
Thanks
^ permalink raw reply
* Re: [PATCH net-next RFC 2/5] vhost: introduce helper to prefetch desc index
From: Jason Wang @ 2017-09-28 7:18 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: virtualization, netdev, linux-kernel, kvm
In-Reply-To: <20170928012906-mutt-send-email-mst@kernel.org>
On 2017年09月28日 06:57, Michael S. Tsirkin wrote:
> On Wed, Sep 27, 2017 at 08:35:47AM +0800, Jason Wang wrote:
>>
>> On 2017年09月27日 03:19, Michael S. Tsirkin wrote:
>>> On Fri, Sep 22, 2017 at 04:02:32PM +0800, Jason Wang wrote:
>>>> This patch introduces vhost_prefetch_desc_indices() which could batch
>>>> descriptor indices fetching and used ring updating. This intends to
>>>> reduce the cache misses of indices fetching and updating and reduce
>>>> cache line bounce when virtqueue is almost full. copy_to_user() was
>>>> used in order to benefit from modern cpus that support fast string
>>>> copy. Batched virtqueue processing will be the first user.
>>>>
>>>> Signed-off-by: Jason Wang <jasowang@redhat.com>
>>>> ---
>>>> drivers/vhost/vhost.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++++++
>>>> drivers/vhost/vhost.h | 3 +++
>>>> 2 files changed, 58 insertions(+)
>>>>
>>>> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
>>>> index f87ec75..8424166d 100644
>>>> --- a/drivers/vhost/vhost.c
>>>> +++ b/drivers/vhost/vhost.c
>>>> @@ -2437,6 +2437,61 @@ struct vhost_msg_node *vhost_dequeue_msg(struct vhost_dev *dev,
>>>> }
>>>> EXPORT_SYMBOL_GPL(vhost_dequeue_msg);
>>>> +int vhost_prefetch_desc_indices(struct vhost_virtqueue *vq,
>>>> + struct vring_used_elem *heads,
>>>> + u16 num, bool used_update)
>>> why do you need to combine used update with prefetch?
>> For better performance
>
> Why is sticking a branch in there better than requesting the update
> conditionally from the caller?
Ok, I get your point, I can split the two functions.
>
>
>
>> and I believe we don't care about the overhead when
>> we meet errors in tx.
> That's a separate question, I do not really understand how
> you can fetch a descriptor and update the used ring at the same
> time. This allows the guest to overwrite the buffer.
> I might be misunderstanding what is going on here though.
We don't update used idx, so guest can't overwrite the buffer I think?
Thanks
^ permalink raw reply
* Re: RFC iproute2 doc files
From: Simon Horman @ 2017-09-28 7:18 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20170920081159.321e426b@xeon-e3>
On Wed, Sep 20, 2017 at 08:11:59AM -0700, Stephen Hemminger wrote:
> I noticed that the iproute man pages are up to date but the LaTex documentation
> is very out of date. Rarely updated since the Linux 2.2 days.
>
> Either someone needs to do a massive editing job on them, or they should just
> be dropped. My preference would be to just drop everything in the doc/ directory.
> The current versions are so old, they can't be helping.
FWIW, removing stale documentation sounds sensible to me.
^ permalink raw reply
* Re: [PATCH net-next RFC 0/5] batched tx processing in vhost_net
From: Jason Wang @ 2017-09-28 7:16 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: virtualization, netdev, linux-kernel, kvm
In-Reply-To: <20170928012009-mutt-send-email-mst@kernel.org>
On 2017年09月28日 06:28, Michael S. Tsirkin wrote:
> On Wed, Sep 27, 2017 at 08:27:37AM +0800, Jason Wang wrote:
>>
>> On 2017年09月26日 21:45, Michael S. Tsirkin wrote:
>>> On Fri, Sep 22, 2017 at 04:02:30PM +0800, Jason Wang wrote:
>>>> Hi:
>>>>
>>>> This series tries to implement basic tx batched processing. This is
>>>> done by prefetching descriptor indices and update used ring in a
>>>> batch. This intends to speed up used ring updating and improve the
>>>> cache utilization.
>>> Interesting, thanks for the patches. So IIUC most of the gain is really
>>> overcoming some of the shortcomings of virtio 1.0 wrt cache utilization?
>> Yes.
>>
>> Actually, looks like batching in 1.1 is not as easy as in 1.0.
>>
>> In 1.0, we could do something like:
>>
>> batch update used ring by user copy_to_user()
>> smp_wmb()
>> update used_idx
>> In 1.1, we need more memory barriers, can't benefit from fast copy helpers?
>>
>> for () {
>> update desc.addr
>> smp_wmb()
>> update desc.flag
>> }
> Yes but smp_wmb is a NOP on e.g. x86. We can switch to other types of
> barriers as well.
We need consider non x86 platforms as well. And we meet similar things
on batch reading.
> We do need to do the updates in order, so we might
> need new APIs for that to avoid re-doing the translation all the time.
>
> In 1.0 the last update is a cache miss always. You need batching to get
> less misses. In 1.1 you don't have it so fundamentally there is less
> need for batching. But batching does not always work. DPDK guys (which
> batch things aggressively) already tried 1.1 and saw performance gains
> so we do not need to argue theoretically.
Do they test on non-x86 CPUs? And the prototype should be reviewed
carefully since a bug can boost the performance in this case.
>
>
>
>>> Which is fair enough (1.0 is already deployed) but I would like to avoid
>>> making 1.1 support harder, and this patchset does this unfortunately,
>> I think the new APIs do not expose more internal data structure of virtio
>> than before? (vq->heads has already been used by vhost_net for years).
> For sure we might need to change vring_used_elem.
>
>> Consider the layout is re-designed completely, I don't see an easy method to
>> reuse current 1.0 API for 1.1.
> Current API just says you get buffers then you use them. It is not tied
> to actual separate used ring.
So do this patch I think? It introduces:
int vhost_prefetch_desc_indices(struct vhost_virtqueue *vq,
struct vring_used_elem *heads,
u16 num);
int vhost_add_used_idx(struct vhost_virtqueue *vq, int n);
There's nothing new exposed to vhost_net. (vring_used_elem has been used
by net.c at many places without this patch).
>
>
>>> see comments on individual patches. I'm sure it can be addressed though.
>>>
>>>> Test shows about ~22% improvement in tx pss.
>>> Is this with or without tx napi in guest?
>> MoonGen is used in guest for better numbers.
>>
>> Thanks
> Not sure I understand. Did you set napi_tx to true or false?
MoonGen uses dpdk, so virtio-net pmd is used in guest. (See
http://conferences.sigcomm.org/imc/2015/papers/p275.pdf)
Thanks
>
>>>> Please review.
>>>>
>>>> Jason Wang (5):
>>>> vhost: split out ring head fetching logic
>>>> vhost: introduce helper to prefetch desc index
>>>> vhost: introduce vhost_add_used_idx()
>>>> vhost_net: rename VHOST_RX_BATCH to VHOST_NET_BATCH
>>>> vhost_net: basic tx virtqueue batched processing
>>>>
>>>> drivers/vhost/net.c | 221 ++++++++++++++++++++++++++++----------------------
>>>> drivers/vhost/vhost.c | 165 +++++++++++++++++++++++++++++++------
>>>> drivers/vhost/vhost.h | 9 ++
>>>> 3 files changed, 270 insertions(+), 125 deletions(-)
>>>>
>>>> --
>>>> 2.7.4
^ permalink raw reply
* Re: [PATCHv3 iproute2 1/2] lib/libnetlink: re malloc buff if size is not enough
From: Hangbin Liu @ 2017-09-28 7:13 UTC (permalink / raw)
To: Michal Kubecek; +Cc: Hangbin Liu, Stephen Hemminger, netdev, Phil Sutter
In-Reply-To: <20170921073420.dcoipli2sxy3bmnx@unicorn.suse.cz>
Hi Michal,
On Thu, Sep 21, 2017 at 09:34:20AM +0200, Michal Kubecek wrote:
> I will have to check but IIRC it might be possible to use zero length
> for the peek to only check the length which could help you to avoid both
> the reallocation and copying the same data from kernel to userspace
> twice.
Yes, msg with zero buf length also works. I will post a new patch after fix.
Thanks
Hangbin
^ permalink raw reply
* Re: [PATCH v6 05/11] dt-bindings: net: dwmac-sun8i: update documentation about integrated PHY
From: Corentin Labbe @ 2017-09-28 7:07 UTC (permalink / raw)
To: Florian Fainelli
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o, andrew-g2DYL2Zd6BY,
frowand.list-Re5JQEeQqe8AvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <25e44368-2c07-9b7e-a0d3-a2a642286e5d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Wed, Sep 27, 2017 at 09:53:15PM -0700, Florian Fainelli wrote:
>
>
> On 09/27/2017 12:34 AM, Corentin Labbe wrote:
> > This patch add documentation about the MDIO switch used on sun8i-h3-emac
> > for integrated PHY.
> >
> > Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > ---
> > .../devicetree/bindings/net/dwmac-sun8i.txt | 138 +++++++++++++++++++--
> > 1 file changed, 126 insertions(+), 12 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
> > index 725f3b187886..e2ef4683df08 100644
> > --- a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
> > +++ b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
> > @@ -4,18 +4,18 @@ This device is a platform glue layer for stmmac.
> > Please see stmmac.txt for the other unchanged properties.
> >
> > Required properties:
> > -- compatible: should be one of the following string:
> > +- compatible: must be one of the following string:
> > "allwinner,sun8i-a83t-emac"
> > "allwinner,sun8i-h3-emac"
> > "allwinner,sun8i-v3s-emac"
> > "allwinner,sun50i-a64-emac"
> > - reg: address and length of the register for the device.
> > - interrupts: interrupt for the device
> > -- interrupt-names: should be "macirq"
> > +- interrupt-names: must be "macirq"
> > - clocks: A phandle to the reference clock for this device
> > -- clock-names: should be "stmmaceth"
> > +- clock-names: must be "stmmaceth"
> > - resets: A phandle to the reset control for this device
> > -- reset-names: should be "stmmaceth"
> > +- reset-names: must be "stmmaceth"
> > - phy-mode: See ethernet.txt
> > - phy-handle: See ethernet.txt
> > - #address-cells: shall be 1
> > @@ -39,23 +39,38 @@ Optional properties for the following compatibles:
> > - allwinner,leds-active-low: EPHY LEDs are active low
> >
> > Required child node of emac:
> > -- mdio bus node: should be named mdio
> > +- mdio bus node: with compatible "snps,dwmac-mdio"
> >
> > Required properties of the mdio node:
> > - #address-cells: shall be 1
> > - #size-cells: shall be 0
> >
> > -The device node referenced by "phy" or "phy-handle" should be a child node
> > +The device node referenced by "phy" or "phy-handle" must be a child node
> > of the mdio node. See phy.txt for the generic PHY bindings.
> >
> > -Required properties of the phy node with the following compatibles:
> > +The following compatibles require that the mdio node have a mdio-mux child
> > +node called "mdio-mux":
> > + - "allwinner,sun8i-h3-emac"
> > + - "allwinner,sun8i-v3s-emac":
> > +Required properties for the mdio-mux node:
> > + - compatible = "mdio-mux"
> > + - one child mdio for the integrated mdio
> > + - one child mdio for the external mdio if present (V3s have none)
> > +Required properties for the mdio-mux children node:
> > + - reg: 1 for internal MDIO bus, 2 for external MDIO bus
> > +
> > +The following compatibles require a PHY node representing the integrated
> > +PHY, under the integrated MDIO bus node if an mdio-mux node is used:
> > - "allwinner,sun8i-h3-emac",
> > - "allwinner,sun8i-v3s-emac":
> > +
> > +Required properties of the integrated phy node:
> > - clocks: a phandle to the reference clock for the EPHY
> > - resets: a phandle to the reset control for the EPHY
> > +- phy-is-integrated
> > +- Must be a child of the integrated mdio
> >
> > -Example:
> > -
> > +Example with integrated PHY:
> > emac: ethernet@1c0b000 {
> > compatible = "allwinner,sun8i-h3-emac";
> > syscon = <&syscon>;
> > @@ -72,13 +87,112 @@ emac: ethernet@1c0b000 {
> > phy-handle = <&int_mii_phy>;
> > phy-mode = "mii";
> > allwinner,leds-active-low;
> > +
> > + mdio0: mdio {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + compatible = "snps,dwmac-mdio";
> > +
> > + mdio-mux {
> > + compatible = "mdio-mux";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
>
> Sorry for chiming in so late, but why don't we have the mdio-mux be the
> root node here in the mdio bus hierarchy? I understand that with this
> binding proposed here, we need to have patch 11 included (which btw,
> should come before any DTS change), but this does not seem to accurately
> model the HW.
>
> The mux itself is not a child node of the MDIO bus controller, it does
> not really belong in that address space although it does mangle the MDIO
> bus controller address space between the two ends of the mux.
>
> If this has been debated before, apologies for missing that part of the
> discussion.
>
I have done it as asked by Rob.
https://lkml.org/lkml/2017/9/13/422
https://lkml.org/lkml/2017/9/19/849
Regards
^ permalink raw reply
* Re: [PATCH net-next RFC 5/5] vhost_net: basic tx virtqueue batched processing
From: Jason Wang @ 2017-09-28 7:02 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: virtualization, netdev, linux-kernel, kvm
In-Reply-To: <20170928011724-mutt-send-email-mst@kernel.org>
On 2017年09月28日 06:19, Michael S. Tsirkin wrote:
> On Wed, Sep 27, 2017 at 10:04:18AM +0800, Jason Wang wrote:
>>
>> On 2017年09月27日 03:25, Michael S. Tsirkin wrote:
>>> On Fri, Sep 22, 2017 at 04:02:35PM +0800, Jason Wang wrote:
>>>> This patch implements basic batched processing of tx virtqueue by
>>>> prefetching desc indices and updating used ring in a batch. For
>>>> non-zerocopy case, vq->heads were used for storing the prefetched
>>>> indices and updating used ring. It is also a requirement for doing
>>>> more batching on top. For zerocopy case and for simplicity, batched
>>>> processing were simply disabled by only fetching and processing one
>>>> descriptor at a time, this could be optimized in the future.
>>>>
>>>> XDP_DROP (without touching skb) on tun (with Moongen in guest) with
>>>> zercopy disabled:
>>>>
>>>> Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz:
>>>> Before: 3.20Mpps
>>>> After: 3.90Mpps (+22%)
>>>>
>>>> No differences were seen with zerocopy enabled.
>>>>
>>>> Signed-off-by: Jason Wang <jasowang@redhat.com>
>>> So where is the speedup coming from? I'd guess the ring is
>>> hot in cache, it's faster to access it in one go, then
>>> pass many packets to net stack. Is that right?
>>>
>>> Another possibility is better code cache locality.
>> Yes, I think the speed up comes from:
>>
>> - less cache misses
>> - less cache line bounce when virtqueue is about to be full (guest is faster
>> than host which is the case of MoonGen)
>> - less memory barriers
>> - possible faster copy speed by using copy_to_user() on modern CPUs
>>
>>> So how about this patchset is refactored:
>>>
>>> 1. use existing APIs just first get packets then
>>> transmit them all then use them all
>> Looks like current API can not get packets first, it only support get packet
>> one by one (if you mean vhost_get_vq_desc()). And used ring updating may get
>> more misses in this case.
> Right. So if you do
>
> for (...)
> vhost_get_vq_desc
>
>
> then later
>
> for (...)
> vhost_add_used
>
>
> then you get most of benefits except maybe code cache misses
> and copy_to_user.
>
If you mean vhost_add_used_n(), then more barriers and userspace memory
access as well. And you still need to cache vring_used_elem in vq->heads
or elsewhere. Since you do not batch reading avail ring indexes, more
write miss will happen if the ring is about to be full. So it looks
slower than what is done in this patch?
And if we want to indo more batching on top (do we want this?), we still
need new APIs anyway.
Thanks
>
>
>
>
>
>>> 2. add new APIs and move the loop into vhost core
>>> for more speedups
>> I don't see any advantages, looks like just need some e.g callbacks in this
>> case.
>>
>> Thanks
> IUC callbacks pretty much destroy the code cache locality advantages,
> IP is jumping around too much.
>
>
^ permalink raw reply
* Re: [PATCH net-next 0/3] support changing steering policies in tuntap
From: Jason Wang @ 2017-09-28 6:50 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: netdev, linux-kernel
In-Reply-To: <20170927230042-mutt-send-email-mst@kernel.org>
On 2017年09月28日 06:13, Michael S. Tsirkin wrote:
> On Wed, Sep 27, 2017 at 04:23:54PM +0800, Jason Wang wrote:
>> Hi all:
>>
>> We use flow caches based flow steering policy now. This is good for
>> connection-oriented communication such as TCP but not for the others
>> e.g connectionless unidirectional workload which cares only about
>> pps. This calls the ability of supporting changing steering policies
>> in tuntap which was done by this series.
>>
>> Flow steering policy was abstracted into tun_steering_ops in the first
>> patch. Then new ioctls to set or query current policy were introduced,
>> and the last patch introduces a very simple policy that select txq
>> based on processor id as an example.
>>
>> Test was done by using xdp_redirect to redirect traffic generated from
>> MoonGen that was running on a remote machine. And I see 37%
>> improvement for processor id policy compared to automatic flow
>> steering policy.
> For sure, if you don't need to figure out the flow hash then you can
> save a bunch of cycles. But I don't think the cpu policy is too
> practical outside of a benchmark.
Well, the aim of the series is to add methods to change the steering
policy, cpu policy is an example. Actually, it may make sense for some
cards which guarantee that all packets belongs to a specific flow goes
into a specific cpu.
>
> Did you generate packets and just send them to tun? If so, this is not a
> typical configuration, is it?
The test was done by:
- generate UDP traffic from a remote machine
- use xdp redirection to do mac swap in guest and forward it back to the
remote machine
> With packets coming e.g. from a real nic
> they might already have the hash pre-calculated, and you won't
> see the benefit.
Yes, I can switch to use this as a example policy.
Thanks
>
>> In the future, both simple and sophisticated policy like RSS or other guest
>> driven steering policies could be done on top.
> IMHO there should be a more practical example before adding all this
> indirection. And it would be nice to understand why this queue selection
> needs to be tun specific.
Actually, we can use fanout policy (as pointed out) by using the API
introduced in this series.
Thanks
>
>> Thanks
>>
>> Jason Wang (3):
>> tun: abstract flow steering logic
>> tun: introduce ioctls to set and get steering policies
>> tun: introduce cpu id based steering policy
>>
>> drivers/net/tun.c | 151 +++++++++++++++++++++++++++++++++++++-------
>> include/uapi/linux/if_tun.h | 8 +++
>> 2 files changed, 136 insertions(+), 23 deletions(-)
>>
>> --
>> 2.7.4
^ permalink raw reply
* Re: [PATCH net-next 2/6] bpf: add meta pointer for direct access
From: Waskiewicz Jr, Peter @ 2017-09-28 5:59 UTC (permalink / raw)
To: Andy Gospodarek, Daniel Borkmann
Cc: davem@davemloft.net, alexei.starovoitov@gmail.com,
john.fastabend@gmail.com, jakub.kicinski@netronome.com,
netdev@vger.kernel.org, mchan@broadcom.com
In-Reply-To: <20170926172140.GB60144@C02RW35GFVH8.dhcp.broadcom.net>
On 9/26/17 10:21 AM, Andy Gospodarek wrote:
> On Mon, Sep 25, 2017 at 08:50:28PM +0200, Daniel Borkmann wrote:
>> On 09/25/2017 08:10 PM, Andy Gospodarek wrote:
>> [...]
>>> First, thanks for this detailed description. It was helpful to read
>>> along with the patches.
>>>
>>> My only concern about this area being generic is that you are now in a
>>> state where any bpf program must know about all the bpf programs in the
>>> receive pipeline before it can properly parse what is stored in the
>>> meta-data and add it to an skb (or perform any other action).
>>> Especially if each program adds it's own meta-data along the way.
>>>
>>> Maybe this isn't a big concern based on the number of users of this
>>> today, but it just starts to seem like a concern as there are these
>>> hints being passed between layers that are challenging to track due to a
>>> lack of a standard format for passing data between.
>>
>> Btw, we do have similar kind of programmable scratch buffer also today
>> wrt skb cb[] that you can program from tc side, the perf ring buffer,
>> which doesn't have any fixed layout for the slots, or a per-cpu map
>> where you can transfer data between tail calls for example, then tail
>> calls themselves that need to coordinate, or simply mangling of packets
>> itself if you will, but more below to your use case ...
>>
>>> The main reason I bring this up is that Michael and I had discussed and
>>> designed a way for drivers to communicate between each other that rx
>>> resources could be freed after a tx completion on an XDP_REDIRECT
>>> action. Much like this code, it involved adding an new element to
>>> struct xdp_md that could point to the important information. Now that
>>> there is a generic way to handle this, it would seem nice to be able to
>>> leverage it, but I'm not sure how reliable this meta-data area would be
>>> without the ability to mark it in some manner.
>>>
>>> For additional background, the minimum amount of data needed in the case
>>> Michael and I were discussing was really 2 words. One to serve as a
>>> pointer to an rx_ring structure and one to have a counter to the rx
>>> producer entry. This data could be acessed by the driver processing the
>>> tx completions and callback to the driver that received the frame off the wire
>>> to perform any needed processing. (For those curious this would also require a
>>> new callback/netdev op to act on this data stored in the XDP buffer.)
>>
>> What you describe above doesn't seem to be fitting to the use-case of
>> this set, meaning the area here is fully programmable out of the BPF
>> program, the infrastructure you're describing is some sort of means of
>> communication between drivers for the XDP_REDIRECT, and should be
>> outside of the control of the BPF program to mangle.
>
> OK, I understand that perspective. I think saying this is really meant
> as a BPF<->BPF communication channel for now is fine.
>
>> You could probably reuse the base infra here and make a part of that
>> inaccessible for the program with some sort of a fixed layout, but I
>> haven't seen your code yet to be able to fully judge. Intention here
>> is to allow for programmability within the BPF prog in a generic way,
>> such that based on the use-case it can be populated in specific ways
>> and propagated to the skb w/o having to define a fixed layout and
>> bloat xdp_buff all the way to an skb while still retaining all the
>> flexibility.
>
> Some level of reuse might be proper, but I'd rather it be explicit for
> my use since it's not exclusively something that will need to be used by
> a BPF prog, but rather the driver. I'll produce some patches this week
> for reference.
Sorry for chiming in late, I've been offline.
We're looking to add some functionality from driver to XDP inside this
xdp_buff->data_meta region. We want to assign it to an opaque
structure, that would be specific per driver (think of a flex descriptor
coming out of the hardware). We'd like to pass these offloaded
computations into XDP programs to help accelerate them, such as packet
type, where headers are located, etc. It's similar to Jesper's RFC
patches back in May when passing through the mlx Rx descriptor to XDP.
This is actually what a few of us are planning to present at NetDev 2.2
in November. If you're hoping to restrict this headroom in the xdp_buff
for an exclusive use case with XDP_REDIRECT, then I'd like to discuss
that further.
-PJ
^ permalink raw reply
* [PATCH net] ip6_tunnel: update mtu properly for ARPHRD_ETHER tunnel device in tx path
From: Xin Long @ 2017-09-28 5:24 UTC (permalink / raw)
To: network dev; +Cc: davem, Dmitry Kozlov
Now when updating mtu in tx path, it doesn't consider ARPHRD_ETHER tunnel
device, like ip6gre_tap tunnel, for which it should also subtract ether
header to get the correct mtu.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
net/ipv6/ip6_tunnel.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index f2f21c2..a1c2444 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -1043,6 +1043,7 @@ int ip6_tnl_xmit(struct sk_buff *skb, struct net_device *dev, __u8 dsfield,
struct dst_entry *dst = NULL, *ndst = NULL;
struct net_device *tdev;
int mtu;
+ unsigned int eth_hlen = t->dev->type == ARPHRD_ETHER ? ETH_HLEN : 0;
unsigned int psh_hlen = sizeof(struct ipv6hdr) + t->encap_hlen;
unsigned int max_headroom = psh_hlen;
bool use_cache = false;
@@ -1124,7 +1125,7 @@ int ip6_tnl_xmit(struct sk_buff *skb, struct net_device *dev, __u8 dsfield,
t->parms.name);
goto tx_err_dst_release;
}
- mtu = dst_mtu(dst) - psh_hlen - t->tun_hlen;
+ mtu = dst_mtu(dst) - eth_hlen - psh_hlen - t->tun_hlen;
if (encap_limit >= 0) {
max_headroom += 8;
mtu -= 8;
@@ -1133,7 +1134,7 @@ int ip6_tnl_xmit(struct sk_buff *skb, struct net_device *dev, __u8 dsfield,
mtu = IPV6_MIN_MTU;
if (skb_dst(skb) && !t->parms.collect_md)
skb_dst(skb)->ops->update_pmtu(skb_dst(skb), NULL, skb, mtu);
- if (skb->len - t->tun_hlen > mtu && !skb_is_gso(skb)) {
+ if (skb->len - t->tun_hlen - eth_hlen > mtu && !skb_is_gso(skb)) {
*pmtu = mtu;
err = -EMSGSIZE;
goto tx_err_dst_release;
--
2.1.0
^ permalink raw reply related
* [PATCH net] ip6_gre: ip6gre_tap device should keep dst
From: Xin Long @ 2017-09-28 5:23 UTC (permalink / raw)
To: network dev; +Cc: davem, Dmitry Kozlov
The patch 'ip_gre: ipgre_tap device should keep dst' fixed
a issue that ipgre_tap mtu couldn't be updated in tx path.
The same fix is needed for ip6gre_tap as well.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
net/ipv6/ip6_gre.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
index 20f66f4..1602b49 100644
--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -1311,6 +1311,7 @@ static void ip6gre_tap_setup(struct net_device *dev)
dev->features |= NETIF_F_NETNS_LOCAL;
dev->priv_flags &= ~IFF_TX_SKB_SHARING;
dev->priv_flags |= IFF_LIVE_ADDR_CHANGE;
+ netif_keep_dst(dev);
}
static bool ip6gre_netlink_encap_parms(struct nlattr *data[],
--
2.1.0
^ permalink raw reply related
* [PATCH net] ip_gre: ipgre_tap device should keep dst
From: Xin Long @ 2017-09-28 5:23 UTC (permalink / raw)
To: network dev; +Cc: davem, Dmitry Kozlov
Without keeping dst, the tunnel will not update any mtu/pmtu info,
since it does not have a dst on the skb.
Reproducer:
client(ipgre_tap1 - eth1) <-----> (eth1 - ipgre_tap1)server
After reducing eth1's mtu on client, then perforamnce became 0.
This patch is to netif_keep_dst in gre_tap_init, as ipgre does.
Reported-by: Jianlin Shi <jishi@redhat.com>
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
net/ipv4/ip_gre.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 0162fb9..8b837f6 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -1223,6 +1223,7 @@ static int gre_tap_init(struct net_device *dev)
{
__gre_tunnel_init(dev);
dev->priv_flags |= IFF_LIVE_ADDR_CHANGE;
+ netif_keep_dst(dev);
return ip_tunnel_init(dev);
}
--
2.1.0
^ permalink raw reply related
* Re: [PATCH net-next 0/3] support changing steering policies in tuntap
From: Tom Herbert @ 2017-09-28 5:02 UTC (permalink / raw)
To: Willem de Bruijn
Cc: Michael S. Tsirkin, Jason Wang, Network Development, LKML
In-Reply-To: <CAF=yD-J8hERZdwq8FJ2rtnCnZ2b7s=CAVLtPk4CS7e=RQH3sLQ@mail.gmail.com>
On Wed, Sep 27, 2017 at 4:25 PM, Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
>>> In the future, both simple and sophisticated policy like RSS or other guest
>>> driven steering policies could be done on top.
>>
>> IMHO there should be a more practical example before adding all this
>> indirection. And it would be nice to understand why this queue selection
>> needs to be tun specific.
>
> I was thinking the same and this reminds me of the various strategies
> implemented in packet fanout. tun_cpu_select_queue is analogous to
> fanout_demux_cpu though it is tun-specific in that it requires tun->numqueues.
>
> Fanout accrued various strategies until it gained an eBPF variant. Just
> supporting BPF is probably sufficient here, too.
+1, in addition to packet fanout, we have SO_REUSEPORT with BPF, RPS,
RFS, etc. It would be nice if existing packet steering mechanisms
could be leveraged for tun.
^ permalink raw reply
* Re: [PATCH v6 05/11] dt-bindings: net: dwmac-sun8i: update documentation about integrated PHY
From: Florian Fainelli @ 2017-09-28 4:53 UTC (permalink / raw)
To: Corentin Labbe, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o, andrew-g2DYL2Zd6BY,
frowand.list-Re5JQEeQqe8AvxtiuMwx3w
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170927073414.17361-6-clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 09/27/2017 12:34 AM, Corentin Labbe wrote:
> This patch add documentation about the MDIO switch used on sun8i-h3-emac
> for integrated PHY.
>
> Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> .../devicetree/bindings/net/dwmac-sun8i.txt | 138 +++++++++++++++++++--
> 1 file changed, 126 insertions(+), 12 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
> index 725f3b187886..e2ef4683df08 100644
> --- a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
> +++ b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
> @@ -4,18 +4,18 @@ This device is a platform glue layer for stmmac.
> Please see stmmac.txt for the other unchanged properties.
>
> Required properties:
> -- compatible: should be one of the following string:
> +- compatible: must be one of the following string:
> "allwinner,sun8i-a83t-emac"
> "allwinner,sun8i-h3-emac"
> "allwinner,sun8i-v3s-emac"
> "allwinner,sun50i-a64-emac"
> - reg: address and length of the register for the device.
> - interrupts: interrupt for the device
> -- interrupt-names: should be "macirq"
> +- interrupt-names: must be "macirq"
> - clocks: A phandle to the reference clock for this device
> -- clock-names: should be "stmmaceth"
> +- clock-names: must be "stmmaceth"
> - resets: A phandle to the reset control for this device
> -- reset-names: should be "stmmaceth"
> +- reset-names: must be "stmmaceth"
> - phy-mode: See ethernet.txt
> - phy-handle: See ethernet.txt
> - #address-cells: shall be 1
> @@ -39,23 +39,38 @@ Optional properties for the following compatibles:
> - allwinner,leds-active-low: EPHY LEDs are active low
>
> Required child node of emac:
> -- mdio bus node: should be named mdio
> +- mdio bus node: with compatible "snps,dwmac-mdio"
>
> Required properties of the mdio node:
> - #address-cells: shall be 1
> - #size-cells: shall be 0
>
> -The device node referenced by "phy" or "phy-handle" should be a child node
> +The device node referenced by "phy" or "phy-handle" must be a child node
> of the mdio node. See phy.txt for the generic PHY bindings.
>
> -Required properties of the phy node with the following compatibles:
> +The following compatibles require that the mdio node have a mdio-mux child
> +node called "mdio-mux":
> + - "allwinner,sun8i-h3-emac"
> + - "allwinner,sun8i-v3s-emac":
> +Required properties for the mdio-mux node:
> + - compatible = "mdio-mux"
> + - one child mdio for the integrated mdio
> + - one child mdio for the external mdio if present (V3s have none)
> +Required properties for the mdio-mux children node:
> + - reg: 1 for internal MDIO bus, 2 for external MDIO bus
> +
> +The following compatibles require a PHY node representing the integrated
> +PHY, under the integrated MDIO bus node if an mdio-mux node is used:
> - "allwinner,sun8i-h3-emac",
> - "allwinner,sun8i-v3s-emac":
> +
> +Required properties of the integrated phy node:
> - clocks: a phandle to the reference clock for the EPHY
> - resets: a phandle to the reset control for the EPHY
> +- phy-is-integrated
> +- Must be a child of the integrated mdio
>
> -Example:
> -
> +Example with integrated PHY:
> emac: ethernet@1c0b000 {
> compatible = "allwinner,sun8i-h3-emac";
> syscon = <&syscon>;
> @@ -72,13 +87,112 @@ emac: ethernet@1c0b000 {
> phy-handle = <&int_mii_phy>;
> phy-mode = "mii";
> allwinner,leds-active-low;
> +
> + mdio0: mdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "snps,dwmac-mdio";
> +
> + mdio-mux {
> + compatible = "mdio-mux";
> + #address-cells = <1>;
> + #size-cells = <0>;
Sorry for chiming in so late, but why don't we have the mdio-mux be the
root node here in the mdio bus hierarchy? I understand that with this
binding proposed here, we need to have patch 11 included (which btw,
should come before any DTS change), but this does not seem to accurately
model the HW.
The mux itself is not a child node of the MDIO bus controller, it does
not really belong in that address space although it does mangle the MDIO
bus controller address space between the two ends of the mux.
If this has been debated before, apologies for missing that part of the
discussion.
> +
> + int_mdio: mdio@1 {
> + reg = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + int_mii_phy: ethernet-phy@1 {
> + reg = <1>;
> + clocks = <&ccu CLK_BUS_EPHY>;
> + resets = <&ccu RST_BUS_EPHY>;
> + phy-is-integrated;
> + };
> + };
> + ext_mdio: mdio@2 {
> + reg = <2>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + };
> + };
> +};
> +
> +Example with external PHY:
> +emac: ethernet@1c0b000 {
> + compatible = "allwinner,sun8i-h3-emac";
> + syscon = <&syscon>;
> + reg = <0x01c0b000 0x104>;
> + interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "macirq";
> + resets = <&ccu RST_BUS_EMAC>;
> + reset-names = "stmmaceth";
> + clocks = <&ccu CLK_BUS_EMAC>;
> + clock-names = "stmmaceth";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + phy-handle = <&ext_rgmii_phy>;
> + phy-mode = "rgmii";
> + allwinner,leds-active-low;
> +
> + mdio0: mdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "snps,dwmac-mdio";
> +
> + mdio-mux {
> + compatible = "mdio-mux";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + int_mdio: mdio@1 {
> + reg = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + int_mii_phy: ethernet-phy@1 {
> + reg = <1>;
> + clocks = <&ccu CLK_BUS_EPHY>;
> + resets = <&ccu RST_BUS_EPHY>;
> + phy-is-integrated;
> + };
> + };
> + ext_mdio: mdio@2 {
> + reg = <2>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + ext_rgmii_phy: ethernet-phy@1 {
> + reg = <1>;
> + };
> + }:
> + };
> + };
> +};
> +
> +Example with SoC without integrated PHY
> +
> +emac: ethernet@1c0b000 {
> + compatible = "allwinner,sun8i-a83t-emac";
> + syscon = <&syscon>;
> + reg = <0x01c0b000 0x104>;
> + interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "macirq";
> + resets = <&ccu RST_BUS_EMAC>;
> + reset-names = "stmmaceth";
> + clocks = <&ccu CLK_BUS_EMAC>;
> + clock-names = "stmmaceth";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + phy-handle = <&ext_rgmii_phy>;
> + phy-mode = "rgmii";
> +
> mdio: mdio {
> + compatible = "snps,dwmac-mdio";
> #address-cells = <1>;
> #size-cells = <0>;
> - int_mii_phy: ethernet-phy@1 {
> + ext_rgmii_phy: ethernet-phy@1 {
> reg = <1>;
> - clocks = <&ccu CLK_BUS_EPHY>;
> - resets = <&ccu RST_BUS_EPHY>;
> };
> };
> };
>
--
Florian
^ permalink raw reply
* Re: [PATCH net-next] net: ipv4: remove fib_weight
From: David Miller @ 2017-09-28 4:51 UTC (permalink / raw)
To: dsahern; +Cc: netdev
In-Reply-To: <1506564480-20374-1-git-send-email-dsahern@gmail.com>
From: David Ahern <dsahern@gmail.com>
Date: Wed, 27 Sep 2017 19:08:00 -0700
> fib_weight in fib_info is set but not used. Remove it and the
> helpers for setting it.
>
> Signed-off-by: David Ahern <dsahern@gmail.com>
Hmmm, I wonder then what Peter intended in commit
0e884c78ee19e902f300ed147083c28a0c6302f0 ("ipv4: L3 hash-based
multipath") because that's where this came from.
^ permalink raw reply
* Re: [PATCH v6 11/11] of: mdio: Prevent of_mdiobus_register from scanning mdio-mux nodes
From: Florian Fainelli @ 2017-09-28 4:50 UTC (permalink / raw)
To: Andrew Lunn, Corentin Labbe
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o, frowand.list-Re5JQEeQqe8AvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170927141213.GF13516-g2DYL2Zd6BY@public.gmane.org>
On 09/27/2017 07:12 AM, Andrew Lunn wrote:
> On Wed, Sep 27, 2017 at 09:34:14AM +0200, Corentin Labbe wrote:
>> Each child node of an MDIO node is scanned as a PHY when calling
>> of_mdiobus_register() givint the following result:
>> [ 18.175379] mdio_bus stmmac-0: /soc/ethernet@1c30000/mdio/mdio-mux has invalid PHY address
>> [ 18.175408] mdio_bus stmmac-0: scan phy mdio-mux at address 0
>> [ 18.175450] mdio_bus stmmac-0: scan phy mdio-mux at address 1
>> [...]
>> [ 18.176420] mdio_bus stmmac-0: scan phy mdio-mux at address 30
>> [ 18.176452] mdio_bus stmmac-0: scan phy mdio-mux at address 31
>>
>> Since mdio-mux nodes are not PHY, this patch a way to to not scan
>> them.
>
> Hi Corentin
>
> I still don't like this, but ...
Me neither, even more so as I don't understand the reasoning behind
putting the mux as a child node of the MDIO bus controller in the first
place.
Also, you need to re-order patches such that this patch comes before the
DTS changes.
>
>>
>> Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> ---
>> drivers/of/of_mdio.c | 10 ++++++++++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
>> index d94dd8b77abd..d90ddb0d90f2 100644
>> --- a/drivers/of/of_mdio.c
>> +++ b/drivers/of/of_mdio.c
>> @@ -190,6 +190,10 @@ int of_mdiobus_register(struct mii_bus *mdio, struct device_node *np)
>> struct device_node *child;
>> bool scanphys = false;
>> int addr, rc;
>> + static const struct of_device_id do_not_scan[] = {
>> + { .compatible = "mdio-mux" },
>> + {}
>> + };
>
> Please rename this to some less generic. What i don't want is other
> compatible strings added here. We want to make the exception for
> muxes, but nothing else. So something like compatible_muxes?
>
> Andrew
>
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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
* Re: [PATCH net] ipv6: fix net.ipv6.conf.all interface DAD handlers
From: Erik Kline @ 2017-09-28 4:47 UTC (permalink / raw)
To: David Miller; +Cc: mcroce, netdev, linux-doc
In-Reply-To: <20170915.141227.723470226137757556.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 604 bytes --]
> Erik, please review.
I apologize for the delay. I see that you've already applied this, and
it's mostly LGTM except I have one thing I'm not seeing clearly.
The documentation accept_dad now claims:
DAD operation and mode on a given interface will be selected according
to the maximum value of conf/{all,interface}/accept_dad.
but I'm try to square this with my reading of the changes to
addrconf_dad_begin(). I think setting all.accept_dad to 0 but
ifname.accept_dad to non-0 still results in the short-circuit call to
addrconf_dad_completed().
Am I just not seeing (thinking) straight?
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4835 bytes --]
^ permalink raw reply
* [net 11/11] net/mlx5: Fix wrong indentation in enable SRIOV code
From: Saeed Mahameed @ 2017-09-28 4:41 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Or Gerlitz, Saeed Mahameed
In-Reply-To: <20170928044132.30940-1-saeedm@mellanox.com>
From: Or Gerlitz <ogerlitz@mellanox.com>
Smatch is screaming:
drivers/net/ethernet/mellanox/mlx5/core/sriov.c:112
mlx5_device_enable_sriov() warn: inconsistent indenting
fix that.
Fixes: 7ecf6d8ff154 ('IB/mlx5: Restore IB guid/policy for virtual functions')
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/sriov.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/sriov.c b/drivers/net/ethernet/mellanox/mlx5/core/sriov.c
index 6c48e9959b65..2a8b529ce6dd 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/sriov.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/sriov.c
@@ -109,7 +109,7 @@ static int mlx5_device_enable_sriov(struct mlx5_core_dev *dev, int num_vfs)
mlx5_core_warn(dev,
"failed to restore VF %d settings, err %d\n",
vf, err);
- continue;
+ continue;
}
}
mlx5_core_dbg(dev, "successfully enabled VF* %d\n", vf);
--
2.13.0
^ permalink raw reply related
* [net 10/11] net/mlx5: Fix static checker warning on steering tracepoints code
From: Saeed Mahameed @ 2017-09-28 4:41 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Matan Barak, Saeed Mahameed
In-Reply-To: <20170928044132.30940-1-saeedm@mellanox.com>
From: Matan Barak <matanb@mellanox.com>
Fix this sparse complaint:
drivers/net/ethernet/mellanox/mlx5/core/./diag/fs_tracepoint.h:172:1:
warning: odd constant _Bool cast (ffffffffffffffff becomes 1)
Fixes: d9fea79171ee ('net/mlx5: Add tracepoints')
Signed-off-by: Matan Barak <matanb@mellanox.com>
Reviewed-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/diag/fs_tracepoint.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/diag/fs_tracepoint.h b/drivers/net/ethernet/mellanox/mlx5/core/diag/fs_tracepoint.h
index 1e3a6c3e4132..80eef4163f52 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/diag/fs_tracepoint.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/diag/fs_tracepoint.h
@@ -139,7 +139,7 @@ TRACE_EVENT(mlx5_fs_del_fg,
{MLX5_FLOW_CONTEXT_ACTION_FWD_NEXT_PRIO, "NEXT_PRIO"}
TRACE_EVENT(mlx5_fs_set_fte,
- TP_PROTO(const struct fs_fte *fte, bool new_fte),
+ TP_PROTO(const struct fs_fte *fte, int new_fte),
TP_ARGS(fte, new_fte),
TP_STRUCT__entry(
__field(const struct fs_fte *, fte)
@@ -149,7 +149,7 @@ TRACE_EVENT(mlx5_fs_set_fte,
__field(u32, action)
__field(u32, flow_tag)
__field(u8, mask_enable)
- __field(bool, new_fte)
+ __field(int, new_fte)
__array(u32, mask_outer, MLX5_ST_SZ_DW(fte_match_set_lyr_2_4))
__array(u32, mask_inner, MLX5_ST_SZ_DW(fte_match_set_lyr_2_4))
__array(u32, mask_misc, MLX5_ST_SZ_DW(fte_match_set_misc))
--
2.13.0
^ permalink raw reply related
* [net 09/11] net/mlx5e: Fix calculated checksum offloads counters
From: Saeed Mahameed @ 2017-09-28 4:41 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Gal Pressman, Saeed Mahameed
In-Reply-To: <20170928044132.30940-1-saeedm@mellanox.com>
From: Gal Pressman <galp@mellanox.com>
Instead of calculating the offloads counters, count them explicitly.
The calculations done for these counters would result in bugs in some
cases, for example:
When running TCP traffic over a VXLAN tunnel with TSO enabled the following
counters would increase:
tx_csum_partial: 1,333,284
tx_csum_partial_inner: 29,286
tx4_csum_partial_inner: 384
tx7_csum_partial_inner: 8
tx9_csum_partial_inner: 34
tx10_csum_partial_inner: 26,807
tx11_csum_partial_inner: 287
tx12_csum_partial_inner: 27
tx16_csum_partial_inner: 6
tx25_csum_partial_inner: 1,733
Seems like tx_csum_partial increased out of nowhere.
The issue is in the following calculation in mlx5e_update_sw_counters:
s->tx_csum_partial = s->tx_packets - tx_offload_none - s->tx_csum_partial_inner;
While tx_packets increases by the number of GSO segments for each SKB,
tx_csum_partial_inner will only increase by one, resulting in wrong
tx_csum_partial counter.
Fixes: bfe6d8d1d433 ("net/mlx5e: Reorganize ethtool statistics")
Signed-off-by: Gal Pressman <galp@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 9 +++------
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c | 3 +++
drivers/net/ethernet/mellanox/mlx5/core/en_stats.h | 6 ++++++
drivers/net/ethernet/mellanox/mlx5/core/en_tx.c | 1 +
4 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index 84b013dc62e9..cc11bbbd0309 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -184,7 +184,6 @@ static void mlx5e_update_sw_counters(struct mlx5e_priv *priv)
struct mlx5e_sw_stats temp, *s = &temp;
struct mlx5e_rq_stats *rq_stats;
struct mlx5e_sq_stats *sq_stats;
- u64 tx_offload_none = 0;
int i, j;
memset(s, 0, sizeof(*s));
@@ -199,6 +198,7 @@ static void mlx5e_update_sw_counters(struct mlx5e_priv *priv)
s->rx_lro_bytes += rq_stats->lro_bytes;
s->rx_csum_none += rq_stats->csum_none;
s->rx_csum_complete += rq_stats->csum_complete;
+ s->rx_csum_unnecessary += rq_stats->csum_unnecessary;
s->rx_csum_unnecessary_inner += rq_stats->csum_unnecessary_inner;
s->rx_xdp_drop += rq_stats->xdp_drop;
s->rx_xdp_tx += rq_stats->xdp_tx;
@@ -229,14 +229,11 @@ static void mlx5e_update_sw_counters(struct mlx5e_priv *priv)
s->tx_queue_dropped += sq_stats->dropped;
s->tx_xmit_more += sq_stats->xmit_more;
s->tx_csum_partial_inner += sq_stats->csum_partial_inner;
- tx_offload_none += sq_stats->csum_none;
+ s->tx_csum_none += sq_stats->csum_none;
+ s->tx_csum_partial += sq_stats->csum_partial;
}
}
- /* Update calculated offload counters */
- s->tx_csum_partial = s->tx_packets - tx_offload_none - s->tx_csum_partial_inner;
- s->rx_csum_unnecessary = s->rx_packets - s->rx_csum_none - s->rx_csum_complete;
-
s->link_down_events_phy = MLX5_GET(ppcnt_reg,
priv->stats.pport.phy_counters,
counter_set.phys_layer_cntrs.link_down_events);
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
index f1dd638384d3..15a1687483cc 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
@@ -627,6 +627,7 @@ static inline void mlx5e_handle_csum(struct net_device *netdev,
if (lro) {
skb->ip_summed = CHECKSUM_UNNECESSARY;
+ rq->stats.csum_unnecessary++;
return;
}
@@ -644,7 +645,9 @@ static inline void mlx5e_handle_csum(struct net_device *netdev,
skb->csum_level = 1;
skb->encapsulation = 1;
rq->stats.csum_unnecessary_inner++;
+ return;
}
+ rq->stats.csum_unnecessary++;
return;
}
csum_none:
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_stats.h b/drivers/net/ethernet/mellanox/mlx5/core/en_stats.h
index 6d199ffb1c0b..f8637213afc0 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_stats.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_stats.h
@@ -68,6 +68,7 @@ struct mlx5e_sw_stats {
u64 rx_xdp_drop;
u64 rx_xdp_tx;
u64 rx_xdp_tx_full;
+ u64 tx_csum_none;
u64 tx_csum_partial;
u64 tx_csum_partial_inner;
u64 tx_queue_stopped;
@@ -108,6 +109,7 @@ static const struct counter_desc sw_stats_desc[] = {
{ MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, rx_xdp_drop) },
{ MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, rx_xdp_tx) },
{ MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, rx_xdp_tx_full) },
+ { MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, tx_csum_none) },
{ MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, tx_csum_partial) },
{ MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, tx_csum_partial_inner) },
{ MLX5E_DECLARE_STAT(struct mlx5e_sw_stats, tx_queue_stopped) },
@@ -339,6 +341,7 @@ struct mlx5e_rq_stats {
u64 packets;
u64 bytes;
u64 csum_complete;
+ u64 csum_unnecessary;
u64 csum_unnecessary_inner;
u64 csum_none;
u64 lro_packets;
@@ -363,6 +366,7 @@ static const struct counter_desc rq_stats_desc[] = {
{ MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, packets) },
{ MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, bytes) },
{ MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, csum_complete) },
+ { MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, csum_unnecessary) },
{ MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, csum_unnecessary_inner) },
{ MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, csum_none) },
{ MLX5E_DECLARE_RX_STAT(struct mlx5e_rq_stats, xdp_drop) },
@@ -392,6 +396,7 @@ struct mlx5e_sq_stats {
u64 tso_bytes;
u64 tso_inner_packets;
u64 tso_inner_bytes;
+ u64 csum_partial;
u64 csum_partial_inner;
u64 nop;
/* less likely accessed in data path */
@@ -408,6 +413,7 @@ static const struct counter_desc sq_stats_desc[] = {
{ MLX5E_DECLARE_TX_STAT(struct mlx5e_sq_stats, tso_bytes) },
{ MLX5E_DECLARE_TX_STAT(struct mlx5e_sq_stats, tso_inner_packets) },
{ MLX5E_DECLARE_TX_STAT(struct mlx5e_sq_stats, tso_inner_bytes) },
+ { MLX5E_DECLARE_TX_STAT(struct mlx5e_sq_stats, csum_partial) },
{ MLX5E_DECLARE_TX_STAT(struct mlx5e_sq_stats, csum_partial_inner) },
{ MLX5E_DECLARE_TX_STAT(struct mlx5e_sq_stats, nop) },
{ MLX5E_DECLARE_TX_STAT(struct mlx5e_sq_stats, csum_none) },
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_tx.c b/drivers/net/ethernet/mellanox/mlx5/core/en_tx.c
index fee43e40fa16..1d6925d4369a 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tx.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tx.c
@@ -193,6 +193,7 @@ mlx5e_txwqe_build_eseg_csum(struct mlx5e_txqsq *sq, struct sk_buff *skb, struct
sq->stats.csum_partial_inner++;
} else {
eseg->cs_flags |= MLX5_ETH_WQE_L4_CSUM;
+ sq->stats.csum_partial++;
}
} else
sq->stats.csum_none++;
--
2.13.0
^ permalink raw reply related
* [net 07/11] net/mlx5e: Print netdev features correctly in error message
From: Saeed Mahameed @ 2017-09-28 4:41 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Gal Pressman, Saeed Mahameed
In-Reply-To: <20170928044132.30940-1-saeedm@mellanox.com>
From: Gal Pressman <galp@mellanox.com>
Use the correct formatting for netdev features.
Fixes: 0e405443e803 ("net/mlx5e: Improve set features ndo resiliency")
Signed-off-by: Gal Pressman <galp@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index dfc29720ab77..84b013dc62e9 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -3333,8 +3333,8 @@ static int mlx5e_handle_feature(struct net_device *netdev,
err = feature_handler(netdev, enable);
if (err) {
- netdev_err(netdev, "%s feature 0x%llx failed err %d\n",
- enable ? "Enable" : "Disable", feature, err);
+ netdev_err(netdev, "%s feature %pNF failed, err %d\n",
+ enable ? "Enable" : "Disable", &feature, err);
return err;
}
--
2.13.0
^ permalink raw reply related
* [net 06/11] net/mlx5e: Check encap entry state when offloading tunneled flows
From: Saeed Mahameed @ 2017-09-28 4:41 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Vlad Buslov, Saeed Mahameed
In-Reply-To: <20170928044132.30940-1-saeedm@mellanox.com>
From: Vlad Buslov <vladbu@mellanox.com>
Encap entries cached by the driver could be invalidated due to
tunnel destination neighbour state changes.
When attempting to offload a flow that uses a cached encap entry,
we must check the entry validity and defer the offloading
if the entry exists but not valid.
When EAGAIN is returned, the flow offloading to hardware takes place
by the neigh update code when the tunnel destination neighbour
becomes connected.
Fixes: 232c001398ae ("net/mlx5e: Add support to neighbour update flow")
Signed-off-by: Vlad Buslov <vladbu@mellanox.com>
Reviewed-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
index d3786005fba7..1aa2028ed995 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@ -1859,6 +1859,7 @@ static int mlx5e_attach_encap(struct mlx5e_priv *priv,
}
}
+ /* must verify if encap is valid or not */
if (found)
goto attach_flow;
@@ -1885,6 +1886,8 @@ static int mlx5e_attach_encap(struct mlx5e_priv *priv,
*encap_dev = e->out_dev;
if (e->flags & MLX5_ENCAP_ENTRY_VALID)
attr->encap_id = e->encap_id;
+ else
+ err = -EAGAIN;
return err;
--
2.13.0
^ permalink raw reply related
* [net 08/11] net/mlx5e: Don't add/remove 802.1ad rules when changing 802.1Q VLAN filter
From: Saeed Mahameed @ 2017-09-28 4:41 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Gal Pressman, Saeed Mahameed
In-Reply-To: <20170928044132.30940-1-saeedm@mellanox.com>
From: Gal Pressman <galp@mellanox.com>
Toggling of C-tag VLAN filter should not affect the "any S-tag" steering rule.
Fixes: 8a271746a264 ("net/mlx5e: Receive s-tagged packets in promiscuous mode")
Signed-off-by: Gal Pressman <galp@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en_fs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_fs.c b/drivers/net/ethernet/mellanox/mlx5/core/en_fs.c
index f11fd07ac4dd..850cdc980ab5 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_fs.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_fs.c
@@ -291,7 +291,7 @@ void mlx5e_enable_vlan_filter(struct mlx5e_priv *priv)
priv->fs.vlan.filter_disabled = false;
if (priv->netdev->flags & IFF_PROMISC)
return;
- mlx5e_del_any_vid_rules(priv);
+ mlx5e_del_vlan_rule(priv, MLX5E_VLAN_RULE_TYPE_ANY_CTAG_VID, 0);
}
void mlx5e_disable_vlan_filter(struct mlx5e_priv *priv)
@@ -302,7 +302,7 @@ void mlx5e_disable_vlan_filter(struct mlx5e_priv *priv)
priv->fs.vlan.filter_disabled = true;
if (priv->netdev->flags & IFF_PROMISC)
return;
- mlx5e_add_any_vid_rules(priv);
+ mlx5e_add_vlan_rule(priv, MLX5E_VLAN_RULE_TYPE_ANY_CTAG_VID, 0);
}
int mlx5e_vlan_rx_add_vid(struct net_device *dev, __always_unused __be16 proto,
--
2.13.0
^ permalink raw reply related
* [net 03/11] net/mlx5: Check device capability for maximum flow counters
From: Saeed Mahameed @ 2017-09-28 4:41 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Raed Salem, Saeed Mahameed
In-Reply-To: <20170928044132.30940-1-saeedm@mellanox.com>
From: Raed Salem <raeds@mellanox.com>
Added check for the maximal number of flow counters attached
to rule (FTE).
Fixes: bd5251dbf156b ('net/mlx5_core: Introduce flow steering destination of type counter')
Signed-off-by: Raed Salem <raeds@mellanox.com>
Reviewed-by: Maor Gottlieb <maorg@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/fs_cmd.c | 8 ++++++++
drivers/net/ethernet/mellanox/mlx5/core/fs_core.h | 11 +++++++++++
include/linux/mlx5/mlx5_ifc.h | 3 ++-
3 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/fs_cmd.c b/drivers/net/ethernet/mellanox/mlx5/core/fs_cmd.c
index e0d0efd903bc..36ecc2b2e187 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/fs_cmd.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/fs_cmd.c
@@ -293,6 +293,9 @@ static int mlx5_cmd_set_fte(struct mlx5_core_dev *dev,
}
if (fte->action & MLX5_FLOW_CONTEXT_ACTION_COUNT) {
+ int max_list_size = BIT(MLX5_CAP_FLOWTABLE_TYPE(dev,
+ log_max_flow_counter,
+ ft->type));
int list_size = 0;
list_for_each_entry(dst, &fte->node.children, node.list) {
@@ -305,12 +308,17 @@ static int mlx5_cmd_set_fte(struct mlx5_core_dev *dev,
in_dests += MLX5_ST_SZ_BYTES(dest_format_struct);
list_size++;
}
+ if (list_size > max_list_size) {
+ err = -EINVAL;
+ goto err_out;
+ }
MLX5_SET(flow_context, in_flow_context, flow_counter_list_size,
list_size);
}
err = mlx5_cmd_exec(dev, in, inlen, out, sizeof(out));
+err_out:
kvfree(in);
return err;
}
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.h b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.h
index 5509a752f98e..48dd78975062 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.h
@@ -52,6 +52,7 @@ enum fs_flow_table_type {
FS_FT_FDB = 0X4,
FS_FT_SNIFFER_RX = 0X5,
FS_FT_SNIFFER_TX = 0X6,
+ FS_FT_MAX_TYPE = FS_FT_SNIFFER_TX,
};
enum fs_flow_table_op_mod {
@@ -260,4 +261,14 @@ void mlx5_cleanup_fs(struct mlx5_core_dev *dev);
#define fs_for_each_dst(pos, fte) \
fs_list_for_each_entry(pos, &(fte)->node.children)
+#define MLX5_CAP_FLOWTABLE_TYPE(mdev, cap, type) ( \
+ (type == FS_FT_NIC_RX) ? MLX5_CAP_FLOWTABLE_NIC_RX(mdev, cap) : \
+ (type == FS_FT_ESW_EGRESS_ACL) ? MLX5_CAP_ESW_EGRESS_ACL(mdev, cap) : \
+ (type == FS_FT_ESW_INGRESS_ACL) ? MLX5_CAP_ESW_INGRESS_ACL(mdev, cap) : \
+ (type == FS_FT_FDB) ? MLX5_CAP_ESW_FLOWTABLE_FDB(mdev, cap) : \
+ (type == FS_FT_SNIFFER_RX) ? MLX5_CAP_FLOWTABLE_SNIFFER_RX(mdev, cap) : \
+ (type == FS_FT_SNIFFER_TX) ? MLX5_CAP_FLOWTABLE_SNIFFER_TX(mdev, cap) : \
+ (BUILD_BUG_ON_ZERO(FS_FT_SNIFFER_TX != FS_FT_MAX_TYPE))\
+ )
+
#endif
diff --git a/include/linux/mlx5/mlx5_ifc.h b/include/linux/mlx5/mlx5_ifc.h
index a528b35a022e..69772347f866 100644
--- a/include/linux/mlx5/mlx5_ifc.h
+++ b/include/linux/mlx5/mlx5_ifc.h
@@ -327,7 +327,8 @@ struct mlx5_ifc_flow_table_prop_layout_bits {
u8 reserved_at_80[0x18];
u8 log_max_destination[0x8];
- u8 reserved_at_a0[0x18];
+ u8 log_max_flow_counter[0x8];
+ u8 reserved_at_a8[0x10];
u8 log_max_flow[0x8];
u8 reserved_at_c0[0x40];
--
2.13.0
^ permalink raw reply related
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