On Thu, Feb 11, 2021 at 11:15 PM Boris Pismenny wrote:
> Changes since v3:
> =
> * Use DDP_TCP ifdefs in iov_iter and skb iterators to minimize impact
> when compiled out (Christoph)
> * Simplify netdev references and reduce the use of
> get_netdev_for_sock
On Sun, Feb 14, 2021 at 8:30 PM David Ahern wrote:
>
> On 2/11/21 2:10 PM, Boris Pismenny wrote:
> >
> > +static int nvme_tcp_teardown_ddp(struct nvme_tcp_queue *queue,
> > + u16 command_id,
> > + struct request *rq)
> > +{
> > + struct
On Sun, Feb 14, 2021 at 8:20 PM David Ahern wrote:
> On 2/11/21 2:10 PM, Boris Pismenny wrote:
> > @@ -223,6 +229,164 @@ static inline size_t nvme_tcp_pdu_last_send(struct
> > nvme_tcp_request *req,
> > return nvme_tcp_pdu_data_left(req) <= len;
> > }
> >
> > +#ifdef CONFIG_TCP_DDP
> > +
>
On Sun, Feb 14, 2021 at 8:20 PM David Ahern wrote:
> On 2/11/21 2:10 PM, Boris Pismenny wrote:
> > @@ -223,6 +229,164 @@ static inline size_t nvme_tcp_pdu_last_send(struct
> > nvme_tcp_request *req,
> > return nvme_tcp_pdu_data_left(req) <= len;
> > }
Hi Dave,
Thanks for the continuous f
On Fri, Feb 12, 2021 at 4:11 PM Nikolay Aleksandrov wrote:
> I got interested and read through the doc, there are a few typos below.
thanks for spotting these, we will fix them
On Tue, Feb 9, 2021 at 4:26 PM Vlad Buslov wrote:
> On Mon 08 Feb 2021 at 22:22, Jakub Kicinski wrote:
> > On Mon, 8 Feb 2021 10:21:21 +0200 Vlad Buslov wrote:
> >> > These operations imply that 7.7.7.5 is configured on some interface on
> >> > the host. Most likely the VF representor itself, as
On Tue, Feb 9, 2021 at 12:01 PM Leon Romanovsky wrote:
>
> On Tue, Feb 09, 2021 at 11:25:33AM +0200, Or Gerlitz wrote:
> > On Tue, Feb 9, 2021 at 8:49 AM Leon Romanovsky wrote:
> >
> > [..]
> >
> > > This is another problem with mlx5 - complete madness
On Tue, Feb 9, 2021 at 8:49 AM Leon Romanovsky wrote:
[..]
> This is another problem with mlx5 - complete madness with config options
> that are not possible to test.
> ➜ kernel git:(rdma-next) grep -h "config MLX"
> drivers/net/ethernet/mellanox/mlx5/core/Kconfig | awk '{ print $2}' | sort
>
On Tue, Feb 9, 2021 at 10:42 AM Or Gerlitz wrote:
> On Sat, Feb 6, 2021 at 7:10 AM Saeed Mahameed wrote:
> > Vlad Buslov says:
>
> > Implement support for VF tunneling
>
> > Currently, mlx5 only supports configuration with tunnel endpoint IP address
> >
On Sat, Feb 6, 2021 at 7:10 AM Saeed Mahameed wrote:
> Vlad Buslov says:
> Implement support for VF tunneling
> Currently, mlx5 only supports configuration with tunnel endpoint IP address on
> uplink representor. Remove implicit and explicit assumptions of tunnel always
> being terminated on up
On Sat, Feb 6, 2021 at 7:10 AM Saeed Mahameed wrote:
> From: Saeed Mahameed
> This series adds the support for VF tunneling.
> Vlad Buslov says:
> =
> Implement support for VF tunneling
> Abstract
> Currently, mlx5 only supports configuration with tunnel endpoint IP address on
On Wed, Feb 3, 2021 at 11:12 AM Sagi Grimberg wrote:
> On 2/1/21 2:04 AM, Boris Pismenny wrote:
> > @@ -290,12 +341,9 @@ int nvme_tcp_setup_ddp(struct nvme_tcp_queue *queue,
> > }
> >
> > req->ddp.command_id = command_id;
> > - req->ddp.sg_table.sgl = req->ddp.first_sgl;
> > -
On Wed, Feb 3, 2021 at 10:54 AM Sagi Grimberg wrote:
> > +static
> > +int nvme_tcp_teardown_ddp(struct nvme_tcp_queue *queue,
> > + u16 command_id,
> > + struct request *rq)
> > +{
> > + struct nvme_tcp_request *req = blk_mq_rq_to_pdu(rq);
> > +
On Wed, Feb 3, 2021 at 11:12 AM Sagi Grimberg wrote:
> > @@ -1841,8 +1913,10 @@ static void __nvme_tcp_stop_queue(struct
> > nvme_tcp_queue *queue)
> > nvme_tcp_restore_sock_calls(queue);
> > cancel_work_sync(&queue->io_work);
> >
> > - if (test_bit(NVME_TCP_Q_OFF_DDP, &queue->fl
On Wed, Feb 3, 2021 at 11:17 AM Sagi Grimberg wrote:
> > @@ -2930,6 +2931,27 @@ static struct nvme_ctrl *nvme_tcp_create_ctrl(struct
> > device *dev,
> > return ERR_PTR(ret);
> > }
> >
> > +static int nvme_tcp_netdev_event(struct notifier_block *this,
> > + un
On Tue, Feb 2, 2021 at 10:08 AM Yishai Hadas wrote:
> Implement devlink port function commands to enable / disable roce.
> This is used to control the roce device capabilities.
[..]
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.h
> @@ -122,8 +122,9 @@ struct mlx5_vport_info {
>
On Mon, Feb 1, 2021 at 7:40 PM Christoph Hellwig wrote:
> Given how much ddp code there is can you split it into a separate file?
mmm, do we need to check the preferences or get to a consensus among
the maintainers for that one?
On Mon, Feb 1, 2021 at 7:39 PM Christoph Hellwig wrote:
>> +static
>> +int nvme_tcp_offload_socket(struct nvme_tcp_queue *queue)
>
> Please use the same coding style as the rest of the file, and not some
> weirdo version.
ack
On Mon, Feb 1, 2021 at 7:38 PM Christoph Hellwig wrote:
> On Mon, Feb 01, 2021 at 12:04:49PM +0200, Boris Pismenny wrote:
> > +static __always_inline __must_check
> > +size_t ddp_copy_to_iter(const void *addr, size_t bytes, struct iov_iter *i)
> > +{
> > + if (unlikely(!check_copy_size(addr, b
On Thu, Oct 15, 2020 at 9:33 PM Andi Kleen wrote:
> On Thu, Oct 15, 2020 at 05:53:40PM +0300, Or Gerlitz wrote:
> > Earlier Intel processors (e.g E5-2650) support the more of classical
> > two stall events (for backend and frontend [1]) and then perf shows
> > the nice meas
Hi,
Earlier Intel processors (e.g E5-2650) support the more of classical
two stall events (for backend and frontend [1]) and then perf shows
the nice measure of stalled cycles per instruction - e.g here where we
have IPC of 0.91 and CSPI (see [2]) of 0.68:
9,568,273,970 cycles
On Fri, Oct 9, 2020 at 1:50 AM Sagi Grimberg wrote:
> > @@ -412,8 +413,6 @@ int nvme_tcp_offload_limits(struct nvme_tcp_queue
> > *queue,
> > queue->ctrl->ctrl.max_segments = limits->max_ddp_sgl_len;
> > queue->ctrl->ctrl.max_hw_sectors =
> > lim
On Tue, Jul 28, 2020 at 10:51 PM Stephen Hemminger
wrote:
> It is only an historical leftover, because 15 yrs ago that is how Alexy did it
So how about putting behind the burden created by this historical leftover
and moving to use the kernel releases as the emitted version?
Or.
On Tue, Jul 28, 2020 at 11:07 PM Saeed Mahameed wrote:
> When setting the PF interface up/down, notify the firmware to update
> uplink state via MODIFY_VPORT_STATE, when E-Switch is enabled.
> This behavior will prevent sending traffic out on uplink port when PF is
> down, such as sending traffic
Stephen,
Taking into account that iproute releases are aligned with the kernel
ones -- is there any real reason for the confusing DDMMYY double
versioning?
I see that even the git tags go after the kernel releases..
Or.
# git remote -v
origin git://git.kernel.org/pub/scm/network/iproute2/iprou
On Tue, Jul 28, 2020 at 12:13 PM Saeed Mahameed wrote:
> From: Eli Cohen
>
> Net devices might be removed. For example, a vxlan device could be
> deleted and its ifnidex would become invalid. Use dev_get_by_index()
> instead of __dev_get_by_index() to hold reference on the device while
> accessin
On Tue, Jul 28, 2020 at 12:16 PM Saeed Mahameed wrote:
> From: Ron Diskin
>
> When setting the PF interface up/down, notify the firmware to update
> uplink state via MODIFY_VPORT_STATE
How this relates to e-switching? the patch touches the e-switch code
but I don't see mentioning of that in the
On Tue, Jul 7, 2020 at 5:57 PM Eli Cohen wrote:
> On Mon, Jul 06, 2020 at 09:13:06AM +0300, Or Gerlitz wrote:
> > On Sun, Jul 5, 2020 at 10:19 AM Eli Cohen wrote:
> >
> > so what are we protecting here against? someone removing the device
> > while the tc rul
On Sun, Jul 5, 2020 at 10:19 AM Eli Cohen wrote:
>
> On Fri, Jul 03, 2020 at 12:33:58PM +0300, Or Gerlitz wrote:
> > On Fri, Jul 3, 2020 at 1:24 AM Saeed Mahameed wrote:
> > > From: Eli Cohen
> > >
> > > Net devices might be removed. For example, a vxla
On Fri, Jul 3, 2020 at 1:24 AM Saeed Mahameed wrote:
> From: Eli Cohen
>
> Net devices might be removed. For example, a vxlan device could be
> deleted and its ifnidex would become invalid. Use dev_get_by_index()
> instead of __dev_get_by_index() to hold reference on the device while
> accessing
On Tue, Oct 22, 2019 at 8:46 PM Yuval Avnery wrote:
> This patchset introduces devlink vdev.
> Currently, legacy tools do not provide a comprehensive solution that can
> be used in both SmartNic and non-SmartNic mode.
> Vdev represents a device that exists on the ASIC but is not necessarily
> vis
On Tue, Oct 22, 2019 at 8:04 AM Saeed Mahameed wrote:
> CPU: Intel(R) Xeon(R) CPU E5-2603 v4 @ 1.70GHz
> NIC: Mellanox Technologies MT27700 Family [ConnectX-4] (100G)
>
> XDP Drop/TX single core:
> NUMA | XDP | Before| After
> ---
> Close | Drop | 11 Mp
On Thu, Sep 26, 2019 at 7:46 PM Jeff Kirsher
wrote:
> This series is sent out as an RFC to verify that our implementation of
> the MFD subsystem is correct to facilitate inner driver communication
> (IDC) between the new "irdma" driver to support Intel's ice and i40e
> drivers.
>
> The changes con
On Mon, Sep 23, 2019 at 5:21 PM wenxu wrote:
> 在 2019/9/23 17:42, John Hurley 写道:
> > On Mon, Sep 23, 2019 at 5:20 AM wenxu wrote:
> >> Hi John & Jakub
> >>
> >> There are some limitations for indirect tc callback work with skip_sw ?
> >>
> > Hi Wenxu,
> > This is not really a limitation.
> > As
Hi Greg,
If this is RTFM could you please point me to the Emm
AFAIR if a stable kernel is not listed at kernel.org than it is EOL by now.
Is this correct?
thanks,
Or.
On Thu, Sep 19, 2019 at 4:46 PM Eric Dumazet wrote:
> On 9/19/19 5:17 AM, Or Gerlitz wrote:
> > On Wed, Sep 11, 2019 at 12:54 AM Eric Dumazet wrote:
> >> When tcp sends a TSO packet, adding a PSH flag on it
> >> reduces the sojourn time of GRO packet in GRO r
On Thu, Sep 19, 2019 at 11:39 AM wrote:
>
> From: wenxu
>
> A vxlan or gretap device offload through indr block methord. If the device
nit: method --> method
> successfully bind with a real hw through indr block call, It also add
> nooffloadcnt counter. This counter will lead the rule add faile
On Wed, Sep 18, 2019 at 2:48 PM Steffen Klassert
wrote:
> This patchset adds support to do GRO/GSO by chaining packets
> of the same flow at the SKB frag_list pointer. This avoids
> the overhead to merge payloads into one big packet, and
> on the other end, if GSO is needed it avoids the overhead
On Wed, Sep 11, 2019 at 12:54 AM Eric Dumazet wrote:
> When tcp sends a TSO packet, adding a PSH flag on it
> reduces the sojourn time of GRO packet in GRO receivers.
>
> This is particularly the case under pressure, since RX queues
> receive packets for many concurrent flows.
>
> A sender can giv
On Thu, Aug 1, 2019 at 3:44 AM Tonghao Zhang wrote:
> On Wed, May 22, 2019 at 12:49 PM Or Gerlitz wrote:
> > On Wed, May 22, 2019 at 4:26 AM Tonghao Zhang
> > wrote:
> > > I review the reps of netronome nfp codes, nfp does't set the
> > > NETIF_F_NETNS_
On Fri, Jul 26, 2019 at 12:24 AM Saeed Mahameed wrote:
>
> On Thu, 2019-07-25 at 19:24 +0800, we...@ucloud.cn wrote:
> > From: wenxu
> >
> > The flow_cls_common_offload prio is zero
> >
> > It leads the invalid table prio in hw.
> >
> > Error: Could not process rule: Invalid argument
> >
> > kern
On Wed, Jun 26, 2019 at 1:03 AM Sagi Grimberg wrote:
>
> > +void rdma_dim(struct dim *dim, u64 completions)
> > +{
> > + struct dim_sample *curr_sample = &dim->measuring_sample;
> > + struct dim_stats curr_stats;
> > + u32 nevents;
> > +
> > + dim_update_sample_with_comps(curr_samp
On Wed, May 22, 2019 at 4:26 AM Tonghao Zhang wrote:
> I review the reps of netronome nfp codes, nfp does't set the
> NETIF_F_NETNS_LOCAL to netdev->features.
> And I changed the OFED codes which used for our product environment,
> and then send this patch to upstream.
The real question here is
On Tue, May 21, 2019 at 7:36 AM Tonghao Zhang wrote:
> On Tue, May 21, 2019 at 4:24 AM Or Gerlitz wrote:
> >
> > On Mon, May 20, 2019 at 3:19 PM wrote:
> > >
> > > From: Tonghao Zhang
> > >
> > > At most case, we use the ConnectX-5 NIC
On Mon, May 20, 2019 at 3:19 PM wrote:
>
> From: Tonghao Zhang
>
> At most case, we use the ConnectX-5 NIC on compute node for VMs,
> but we will offload forwarding rules to NICs on gateway node.
> On the gateway node, we will install multiple NICs and set them to
> different dockers which contai
On Fri, May 17, 2019 at 12:45 PM wrote:
> From: wenxu
>
> The mlx5e support the lag mode. When add mlx_p0 and mlx_p1 to bond0.
> packet received from mlx_p0 or mlx_p1 and in the ingress tc flower
> forward to vf0. The tc rule can't be offloaded because there is
> no indr_register_block for the bo
On Wed, Mar 27, 2019 at 3:36 PM Leon Romanovsky wrote:
> On Wed, Mar 27, 2019 at 01:58:17PM +0200, Or Gerlitz wrote:
> > On Wed, Mar 27, 2019 at 1:41 PM Leon Romanovsky wrote:
> > > On Wed, Mar 27, 2019 at 12:07:54PM +0200, Or Gerlitz wrote:
> > > > On Tue,
On Wed, Mar 27, 2019 at 1:41 PM Leon Romanovsky wrote:
> On Wed, Mar 27, 2019 at 12:07:54PM +0200, Or Gerlitz wrote:
> > On Tue, Mar 19, 2019 at 11:25 AM Leon Romanovsky wrote:
> > > From: Artemy Kovalyov
> > >
> > > Delete initialization of high o
-off-by: Leon Romanovsky
Reported-by: Shalom Toledo
Acked-by: Or Gerlitz
Lets push it into stable kernels, a Fixes tag here will cause that
to happen more easily, so please consider that.
> ---
> .../net/ethernet/mellanox/mlx5/core/main.c| 20 ---
> 1 file changed,
On Mon, Feb 25, 2019 at 1:07 PM wrote:
> The encapsulation is not supported for mlx5 VFs. When we try to
> offload that action, the -EINVAL is returned, but not -EOPNOTSUPP.
> This patch changes the returned value and ignore to confuse user.
FWIW, note that this changes the behavior towards user
On Mon, Feb 25, 2019 at 1:06 PM wrote:
> When max modify header action is zero, we return -EOPNOTSUPP
> directly. In this way, we can ignore wrong message info (e.g.
> "mlx5: parsed 0 pedit actions, can't do more").
>
> This happens when offloading pedit actions on mlx VFs.
this command should w
On Sat, Feb 23, 2019 at 9:58 AM Tonghao Zhang wrote:
> On Fri, Feb 22, 2019 at 5:07 PM Or Gerlitz wrote:
> > On Fri, Feb 22, 2019 at 9:49 AM Tonghao Zhang
> > wrote:
> > > On Fri, Feb 22, 2019 at 12:32 AM Or Gerlitz wrote:
> > > > On
On Fri, Feb 22, 2019 at 12:35 AM Saeed Mahameed wrote:
> On Thu, 2019-02-21 at 12:21 +0200, Or Gerlitz wrote:
> So we all agree that the offending patch is "net/mlx5e: Support tunnel
> encap over tagged Ethernet" even if the issue existed before,
as you said the issue exis
On Fri, Feb 22, 2019 at 9:49 AM Tonghao Zhang wrote:
>
> On Fri, Feb 22, 2019 at 12:32 AM Or Gerlitz wrote:
> >
> > On Thu, Feb 21, 2019 at 3:42 PM wrote:
> > >
> > > From: Tonghao Zhang
> > >
> > > If we try to offload decapsulation
On Thu, Feb 21, 2019 at 3:42 PM wrote:
> From: Tonghao Zhang
>
> This patch allow users to enable/disable VFs link state
> on switchdev mode.
NAK
We do it with the reps, if you change the administrative link state of a VF rep
it will effect the operational link state of the VF, see upstream com
On Thu, Feb 21, 2019 at 3:42 PM wrote:
>
> From: Tonghao Zhang
>
> If we try to offload decapsulation actions to VFs hw, we get the log [1].
but the switching was on the tunnel type (if (tunnel_type == [...]) -
what rules caused you to get here?
what was the ingress device and what was the egre
On Thu, Feb 21, 2019 at 3:42 PM wrote:
> else /* namespace is MLX5_FLOW_NAMESPACE_KERNEL - NIC offloading */
> max_actions = MLX5_CAP_FLOWTABLE_NIC_RX(priv->mdev,
> max_modify_header_actions);
>
> + if (!max_actions) {
> + NL_SET_ERR_MSG_MOD(extack,
> +
On Wed, Feb 20, 2019 at 10:03 PM Saeed Mahameed wrote:
> On Tue, 2019-02-19 at 22:36 -0800, David Miller wrote:
>> I need help backporting two changes for -stable. Namely:
> Hi Dave Thanks for trying,
here too
> > 6707f74be8621ae067d2cf1c4485900e2742c20f ("net/mlx5e: Update hw flows
> > when e
l will
> > flush all the neighbour on the netdevice and send
> > NETEVENT_NEIGH_UPDATE
> > event. The mlx5 driver will delete the flows and add them when
> > neighbour
> > available again.
> >
> > Fixes: 232c001398ae ("net/mlx5e: Add support to neighbour update
> >
On Sat, Feb 2, 2019 at 5:19 PM Tonghao Zhang wrote:
> The patch [1] is ready too. David may decide which one will be applied
> firstly. and other is rebased ?.
Your patch is for net, net-next is rebased over net
> [1] http://patchwork.ozlabs.org/patch/1032952/
On Sat, Feb 2, 2019 at 5:19 PM Tonghao Zhang wrote:
> The patch [1] is ready too. David may decide which one will be applied
> firstly. and other is rebased ?.
Your patch is for net, net-next is rebased over net
> [1] http://patchwork.ozlabs.org/patch/1032952/
On Thu, Jan 31, 2019 at 10:49 PM Or Gerlitz wrote:
>
> On Thu, Jan 31, 2019 at 4:11 PM wrote:
> > From: Tonghao Zhang
> >
> > Add the tab before '}' and keep the code style consistent.
> >
> > Signed-off-by: Tonghao Zhang
>
> LGTM
> Revi
On Thu, Jan 31, 2019 at 4:11 PM wrote:
> From: Tonghao Zhang
>
> Add the tab before '}' and keep the code style consistent.
>
> Signed-off-by: Tonghao Zhang
LGTM
Reviewed-by: Or Gerlitz
ll store the max pedit action number we support and
> num_mod_hdr_actions indicates how many pedit action we used, and store all
> pedit action to mod_hdr_actions.
>
> Fixes: d79b6df6b10a ("net/mlx5e: Add parsing of TC pedit actions to HW
> format")
> Cc: Or Gerlitz
> Signed-off-by:
hem when neighbour
> available again.
>
> Fixes: 232c001398ae ("net/mlx5e: Add support to neighbour update flow")
> Cc: Hadar Hen Zion
> Signed-off-by: Tonghao Zhang
> Reviewed-by: Or Gerlitz
This is good to go upstream, well done Tonghao!
On Mon, Jan 28, 2019 at 6:18 PM Tonghao Zhang wrote:
> On Mon, Jan 28, 2019 at 11:34 PM Or Gerlitz wrote:
> > On Mon, Jan 28, 2019 at 2:10 PM Tonghao Zhang
> > wrote:
> > > On Mon, Jan 28, 2019 at 12:40 AM Or Gerlitz wrote:
> > > >
> >
On Mon, Jan 28, 2019 at 2:10 PM Tonghao Zhang wrote:
> On Mon, Jan 28, 2019 at 12:40 AM Or Gerlitz wrote:
> >
> > On Sun, Jan 27, 2019 at 1:06 PM wrote:
> > > From: Tonghao Zhang
> > >
> > > In some case, we may use multiple pedit actions to modify
On Sun, Jan 27, 2019 at 1:06 PM wrote:
> From: Tonghao Zhang
>
> In some case, we may use multiple pedit actions to modify packets.
> The command shown as below: the last pedit action is effective.
> @@ -2073,7 +2076,8 @@ static int alloc_mod_hdr_actions(struct mlx5e_priv
> *priv,
> if
when neighbour
> available again.
>
> Fixes: 232c001398ae ("net/mlx5e: Add support to neighbour update flow")
> Cc: Hadar Hen Zion
> Signed-off-by: Tonghao Zhang
> Reviewed-by: Or Gerlitz
+1 again
this one is good to go upstream
On Tue, Jan 22, 2019 at 4:38 PM wrote:
> From: Tonghao Zhang
>
> In some case, we may use multiple pedit actions to modify packets.
just to clarify, this is a matter of choice, right? in other words, it
doesn't buy you extra functionality
> The command shown as below: the last pedit action is e
On Tue, Jan 22, 2019 at 4:38 PM wrote:
>
> From: Tonghao Zhang
>
> In some case, we may use multiple pedit actions to modify packets.
> The command shown as below: the last pedit action is effective.
>
> $ tc filter add dev netdev_rep parent : protocol ip prio 1 \
> flower skip_sw ip
On Sat, Jan 19, 2019 at 10:50 AM Tonghao Zhang wrote:
> On Fri, Jan 18, 2019 at 10:19 PM Or Gerlitz wrote:
> > On Thu, Jan 17, 2019 at 3:34 PM Tonghao Zhang
> > wrote:
> > > On Thu, Jan 17, 2019 at 8:58 PM Or Gerlitz wrote:
> > > > On Thu, Jan 17, 201
when neighbour
> available again.
>
> Fixes: 232c001398ae ("net/mlx5e: Add support to neighbour update flow")
> Cc: Hadar Hen Zion
> Signed-off-by: Tonghao Zhang
LGTM
Reviewed-by: Or Gerlitz
On Mon, Jan 21, 2019 at 1:20 PM wrote:
>
> From: Tonghao Zhang
>
> When we offload tc filters to hardware, hardware flows can
> be updated when mac of encap destination ip is changed.
> But we ignore one case, that the mac of local encap ip can
> be changed too, so we should also update them.
>
>
On Thu, Jan 17, 2019 at 3:34 PM Tonghao Zhang wrote:
> On Thu, Jan 17, 2019 at 8:58 PM Or Gerlitz wrote:
> > On Thu, Jan 17, 2019 at 11:28 AM wrote:
> > > From: Tonghao Zhang
> with this patch, run the command [2], we will not get err log,
> and the filter work in
On Fri, Jan 11, 2019 at 4:19 PM wrote:
>
> From: Tonghao Zhang
We have common prefix, please use it:
net/mlx5e: Update offloaded flows when encap source mac changed
> When we offload tc filters to hardware, hardware flows can
> be updated when mac of encap destination ip is changed.
> But we i
"can't offload re-write of non TCP/UDP");
but under your patch we will not err for unknown ip protocol
I have lost you
BTW - I plan to change the polarity of the check here with the below
patch - please see if it helps your use-case:
commit 09b97
On Thu, Jan 10, 2019 at 3:05 PM Adi Nissim wrote:
> Change the id parameter of the tunnel_key set action from mandatory to
> optional.
> Some tunneling protocols (e.g. GRE) specify the id as an optional field.
Hi,
The kernel code for the tunnel key actions allows keyless tunnels as
of 5.0 (commi
On Thu, Dec 20, 2018 at 2:35 PM Pablo Neira Ayuso wrote:
> On Wed, Dec 19, 2018 at 04:26:53PM -0800, Jakub Kicinski wrote:
> > I'm confused, could you rephrase? How does you work help such devices?
> > How is tc not suitable for them?
> There are two HW offload usecases:
>
> #1 Policy resides i
On Thu, Dec 20, 2018 at 4:47 AM Stephen Rothwell wrote:
>
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
> drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
>
> between commit:
>
> 8956f0014ea5 ("net/mlx5e: Fix default amount of channels for VF
> representors"
/bond device and this way we break vf lag
> if (uplink_upper &&
> netif_is_lag_master(uplink_upper) &&
> uplink_upper == out_dev)
should move it here, after we realize that and potentially made
out_dev be the uplink rep
Otherwise, Acked- by: Or Gerlitz
t duplicated rules also
> under skip_sw")
> Signed-off-by: Roi Dayan
> Reviewed-by: Vlad Buslov
Acked-by: Or Gerlitz
On Mon, Dec 17, 2018 at 11:29 PM Saeed Mahameed
wrote:
> On Sun, Dec 16, 2018 at 4:25 PM Stephen Rothwell
> wrote:
> > I fixed it up (see below) and can carry the fix as necessary. This
> Looks good to me.
here too
> > Today's linux-next merge of the net-next tree got a conflict in:
> > d
On Wed, Dec 12, 2018 at 12:17 AM Jakub Kicinski
wrote:
>
> On Tue, 11 Dec 2018 22:59:47 +0200, Or Gerlitz wrote:
> > To put it a bit more clearly, donno if my concerns are to the extent of
> > being fundamental, but yesknow that they were not sufficiently addressed.
> &g
On Tue, Dec 11, 2018 at 9:15 PM David Miller wrote:
> From: Florian Westphal
> > Pablo Neira Ayuso wrote:
> >> This is another iteration of the in-kernel intermediate representation
> >> (IR) that allows to express ACL hardware offloads using one unified
> >> representation from the driver side
Oz Shlomo
> > Reviewed-by: Eli Britstein
> > Reviewed-by: Jiri Pirko
> > Cc: John Hurley
> > Cc: Jakub Kicinski
> > Signed-off-by: Saeed Mahameed
> Signed-off-by: Jakub Kicinski
> Thank you!
Here too
Acked-by: Or Gerlitz
and let egdev RIP..
On Mon, Dec 10, 2018 at 10:09 PM Saeed Mahameed
wrote:
>
> On Mon, Dec 10, 2018 at 8:12 AM Jason Gunthorpe wrote:
> >
> > On Sun, Dec 09, 2018 at 07:04:39PM -0800, Saeed Mahameed wrote:
> > > From: Eli Britstein
> > >
> > > Change the driver flow destination struct to use bit flags with the vhca
On Mon, Dec 10, 2018 at 6:31 PM Jason Gunthorpe wrote:
> On Sun, Dec 09, 2018 at 07:04:39PM -0800, Saeed Mahameed wrote:
> > From: Eli Britstein
> >
> > Change the driver flow destination struct to use bit flags with the vhca
> > id valid being the 1st one. Done to avoid bool fields in structs, a
On Mon, Dec 10, 2018 at 3:38 AM Stephen Rothwell wrote:
>
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
> net/sched/cls_flower.c
>
> between commit:
>
> 35cc3cefc4de ("net/sched: cls_flower: Reject duplicated rules also under
> skip_sw")
>
> from the net tre
Currently, duplicated rules are rejected only for skip_hw or "none",
hence allowing users to push duplicates into HW for no reason.
Use the flower tables to protect for that.
Signed-off-by: Or Gerlitz
Signed-off-by: Paul Blakey
Reported-by: Chris Mi
---
changes from RFC:
- prope
Currently, duplicated rules are rejected only for skip_hw or "none",
hence allowing users to push duplicated into HW for no reason.
Use the flower tables to protect for that.
Signed-off-by: Or Gerlitz
Signed-off-by: Paul Blakey
Reported-by: Chris Mi
---
net/sched/cls_flo
This short series from Adi Nissim allows to support key-less tunnels
by the tc tunnel key actions, which is needed for some GRE use-cases.
changes from V0:
- addresses build warning spotted by kbuild, make sure to always init
to zero the tunnel key
Adi Nissim (2):
net/sched: act_tunnel_key:
From: Adi Nissim
It's possible to set a tunnel without a destination port. However,
on dump(), a zero dst port is returned to user space even if it was not
set, fix that.
Note that so far it wasn't required, b/c key less tunnels were not
supported and the UDP tunnels do require destination port.
From: Adi Nissim
Allow setting a tunnel without a tunnel key. This is required for
tunneling protocols, such as GRE, that define the key as an optional
field.
Signed-off-by: Adi Nissim
Acked-by: Or Gerlitz
Reviewed-by: Oz Shlomo
Acked-by: Jiri Pirko
---
net/sched/act_tunnel_key.c | 21
From: Adi Nissim
It's possible to set a tunnel without a destination port. However,
on dump(), a zero dst port is returned to user space even if it was not
set, fix that.
Note that so far it wasn't required, b/c key less tunnels were not
supported and the UDP tunnels do require destination port.
This short series from Adi Nissim allows to support key-less tunnels
by the tc tunnel key actions, which is needed for some GRE use-cases.
Adi Nissim (2):
net/sched: act_tunnel_key: Allow key-less tunnels
net/sched: act_tunnel_key: Don't dump dst port if it wasn't set
net/sched/act_tunnel_ke
From: Adi Nissim
Allow setting a tunnel without a tunnel key. This is required for
tunneling protocols, such as GRE, that define the key as an optional
field.
Signed-off-by: Adi Nissim
Acked-by: Or Gerlitz
Reviewed-by: Oz Shlomo
Acked-by: Jiri Pirko
---
net/sched/act_tunnel_key.c | 19
On Mon, Nov 19, 2018 at 10:14 PM David Miller wrote:
> From: Pablo Neira Ayuso
> Date: Mon, 19 Nov 2018 01:15:07 +0100
>
> > This patchset introduces a kernel intermediate representation (IR) to
> > express ACL hardware offloads, as already described in previous RFC and
> > v1 patchset [1] [2]. T
On Fri, Nov 16, 2018 at 3:43 AM Pablo Neira Ayuso wrote:
> This patchset introduces a kernel intermediate representation (IR) to
> express ACL hardware offloads, this is heavily based on the existing
> flow dissector infrastructure and the TC actions. This IR can be used by
> different frontend AC
On Mon, Nov 12, 2018 at 6:13 AM Jakub Kicinski
wrote:
> On Sun, 11 Nov 2018 09:55:35 -0800 (PST), David Miller wrote:
> > From: Jakub Kicinski
> > Date: Fri, 9 Nov 2018 21:21:25 -0800
> >
> > > John says:
> > >
> > > This patchset introduces an alternative to egdev offload by allowing a
> > > dr
1 - 100 of 1065 matches
Mail list logo
