Re: [dpdk-dev] [PATCH] examples/ipsec-secgw: update default configuration
@Akhil, do we need this submitted to dpdk-stable? Acked-by: Anoob Joseph > -Original Message- > From: Lukasz Bartosik > Sent: Wednesday, November 6, 2019 9:18 PM > To: konstantin.anan...@intel.com; akhil.go...@nxp.com; > radu.nico...@intel.com > Cc: dev@dpdk.org; Anoob Joseph ; Lukas Bartosik > > Subject: [PATCH] examples/ipsec-secgw: update default configuration > > Update default configuration of ipsec-secgw: > 1.In ep0.cfg change SPI value used by two inbound IPv6 security policies from > 15 > to 115 and 16 to 116 to point to existing inbound SAs. There are no inbound > SAs > with SPI value 15, 16. > - In ep1.cfg change SPI value used by two outbound IPv6 security policies from > 15 to 115 and 16 to 116 to point to existing outbound SAs. There are no > outbound SAs with SPI value 15, 16. Add missing priority parameter in two > inbound IPv4 security policies. > > Signed-off-by: Lukasz Bartosik > --- > examples/ipsec-secgw/ep0.cfg | 8 examples/ipsec-secgw/ep1.cfg | > 12 ++-- > 2 files changed, 10 insertions(+), 10 deletions(-) > > diff --git a/examples/ipsec-secgw/ep0.cfg b/examples/ipsec-secgw/ep0.cfg > index 299aa9e..dfd4aca 100644 > --- a/examples/ipsec-secgw/ep0.cfg > +++ b/examples/ipsec-secgw/ep0.cfg > @@ -49,14 +49,14 @@ sport 0:65535 dport 0:65535 sp ipv6 out esp protect 26 > pri 1 dst :::::::/96 \ sport 0:65535 dport > 0:65535 > > -sp ipv6 in esp protect 15 pri 1 dst > :::::::/96 > \ -sport 0:65535 dport 0:65535 -sp ipv6 in esp protect 16 pri 1 dst > :::::::/96 \ -sport 0:65535 dport 0:65535 > sp ipv6 in esp protect 110 pri 1 dst > :::::::/96 > \ sport 0:65535 dport 0:65535 sp ipv6 in esp protect 111 pri 1 dst > :::::::/96 \ sport 0:65535 dport 0:65535 > +sp ipv6 in esp protect 115 pri 1 dst > +:::::::/96 \ sport 0:65535 dport > +0:65535 sp ipv6 in esp protect 116 pri 1 dst > +:::::::/96 \ sport 0:65535 dport > +0:65535 > sp ipv6 in esp protect 125 pri 1 dst > :::::::/96 \ sport 0:65535 dport 0:65535 sp > ipv6 in esp protect 126 pri 1 dst :::::::/96 \ > diff --git a/examples/ipsec-secgw/ep1.cfg b/examples/ipsec-secgw/ep1.cfg > index 3f6ff81..19bdc68 100644 > --- a/examples/ipsec-secgw/ep1.cfg > +++ b/examples/ipsec-secgw/ep1.cfg > @@ -19,8 +19,8 @@ sp ipv4 in esp protect 15 pri 1 dst 192.168.200.0/24 sport > 0:65535 dport 0:65535 sp ipv4 in esp protect 16 pri 1 dst 192.168.201.0/24 > sport > 0:65535 dport 0:65535 sp ipv4 in esp protect 25 pri 1 dst 192.168.55.0/24 > sport > 0:65535 dport 0:65535 sp ipv4 in esp protect 26 pri 1 dst 192.168.56.0/24 > sport > 0:65535 dport 0:65535 -sp ipv4 in esp bypass dst 192.168.240.0/24 sport > 0:65535 dport 0:65535 -sp ipv4 in esp bypass dst 192.168.241.0/24 sport > 0:65535 dport 0:65535 > +sp ipv4 in esp bypass pri 1 dst 192.168.240.0/24 sport 0:65535 dport > +0:65535 sp ipv4 in esp bypass pri 1 dst 192.168.241.0/24 sport 0:65535 > +dport 0:65535 > > sp ipv4 out esp protect 105 pri 1 dst 192.168.115.0/24 sport 0:65535 dport > 0:65535 sp ipv4 out esp protect 106 pri 1 dst 192.168.116.0/24 sport 0:65535 > dport 0:65535 @@ -49,14 +49,14 @@ sport 0:65535 dport 0:65535 sp ipv6 in > esp protect 26 pri 1 dst :::::::/96 \ sport > 0:65535 dport 0:65535 > > -sp ipv6 out esp protect 15 pri 1 dst > :::::::/96 \ -sport 0:65535 dport 0:65535 - > sp ipv6 out esp protect 16 pri 1 dst > :::::::/96 \ -sport 0:65535 dport 0:65535 > sp ipv6 out esp protect 110 pri 1 dst > :::::::/96 \ sport 0:65535 dport 0:65535 sp > ipv6 out esp protect 111 pri 1 dst :::::::/96 > \ sport 0:65535 dport 0:65535 > +sp ipv6 out esp protect 115 pri 1 dst > +:::::::/96 \ sport 0:65535 dport > +0:65535 sp ipv6 out esp protect 116 pri 1 dst > +:::::::/96 \ sport 0:65535 dport > +0:65535 > sp ipv6 out esp protect 125 pri 1 dst > :::::::/96 \ sport 0:65535 dport 0:65535 sp > ipv6 out esp protect 126 pri 1 dst :::::::/96 > \ > -- > 2.7.4
Re: [dpdk-dev] [PATCH] net/sfc/base: add missing SPDX license header
On 11/8/19 8:19 PM, Stephen Hemminger wrote: The meson.build file is missing the required license header. Signed-off-by: Stephen Hemminger --- drivers/net/sfc/base/meson.build | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/sfc/base/meson.build b/drivers/net/sfc/base/meson.build index 6c80305820ce..5fbe24014ec6 100644 --- a/drivers/net/sfc/base/meson.build +++ b/drivers/net/sfc/base/meson.build @@ -1,3 +1,5 @@ +# SPDX-License-Identifier: BSD-3-Clause +# # Copyright (c) 2016-2018 Solarflare Communications Inc. # All rights reserved. # It is already fixed in next-net.
Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet size
Hi
From: Ferruh Yigit
> On 11/8/2019 11:56 AM, Matan Azrad wrote:
> >
> >
> > From: Ferruh Yigit
> >> On 11/8/2019 10:10 AM, Matan Azrad wrote:
> >>>
> >>>
> >>> From: Ferruh Yigit
> On 11/8/2019 6:54 AM, Matan Azrad wrote:
> > Hi
> >
> > From: Ferruh Yigit
> >> On 11/7/2019 12:35 PM, Dekel Peled wrote:
> >>> @@ -1266,6 +1286,18 @@ struct rte_eth_dev *
> >>>
> >>RTE_ETHER_MAX_LEN;
> >>> }
> >>>
> >>> + /*
> >>> + * If LRO is enabled, check that the maximum aggregated
> >> packet
> >>> + * size is supported by the configured device.
> >>> + */
> >>> + if (dev_conf->rxmode.offloads &
> >> DEV_RX_OFFLOAD_TCP_LRO) {
> >>> + ret = check_lro_pkt_size(
> >>> + port_id, dev_conf-
> >>> rxmode.max_lro_pkt_size,
> >>> + dev_info.max_lro_pkt_size);
> >>> + if (ret != 0)
> >>> + goto rollback;
> >>> + }
> >>> +
> >>
> >> This check forces applications that enable LRO to provide
> 'max_lro_pkt_size'
> >> config value.
> >
> > Yes.(we can break an API, we noticed it)
>
> I am not talking about API/ABI breakage, that part is OK.
> With this check, if the application requested LRO offload but not
> provided 'max_lro_pkt_size' value, device configuration will fail.
>
> >>> Yes
> Can there be a case application is good with whatever the PMD can
> support as max?
> >>> Yes can be - you know, we can do everything we want but it is better
> >>> to be
> >> consistent:
> >>> Due to the fact of Max rx pkt len field is mandatory for JUMBO
> >>> offload, max
> >> lro pkt len should be mandatory for LRO offload.
> >>>
> >>> So your question is actually why both, non-lro packets and LRO
> >>> packets max
> >> size are mandatory...
> >>>
> >>>
> >>> I think it should be important values for net applications management.
> >>> Also good for mbuf size managements.
> >>>
> >
> >> - Why it is mandatory now, how it was working before if it is
> >> mandatory value?
> >
> > It is the same as max_rx_pkt_len which is mandatory for jumbo
> > frame
> offload.
> > So now, when the user configures a LRO offload he must to set max
> > lro pkt
> len.
> > We don't want to confuse the user here with the max rx pkt len
> configurations and behaviors, they should be with same logic.
> >
> > This parameter defines well the LRO behavior.
> > Before this, each PMD took its own interpretation to what should
> > be the
> maximum size for LRO aggregated packets.
> > Now, the user must say what is his intension, and the ethdev can
> > limit it
> according to the device capability.
> > By this way, also, the PMD can organize\optimize its data-path more.
> > Also, the application can create different mempools for LRO queues
> > to
> allow bigger packet receiving for LRO traffic.
> >
> >> - What happens if PMD doesn't provide 'max_lro_pkt_size', so it is
> '0'?
> > Yes, you can see the feature description Dekel added.
> > This patch also updates all the PMDs support an LRO for non-0 value.
>
> Of course I can see the updates Matan, my point is "What happens if
> PMD doesn't provide 'max_lro_pkt_size'",
> 1) There is no check for it right, so it is acceptable?
> >>>
> >>> There is check.
> >>> If the capability is 0, any non-zero configuration will fail.
> >>>
> 2) Are we making this filed mandatory to provide for PMDs, it is
> easy to make new fields mandatory for PMDs but is this really
> necessary?
> >>>
> >>> Yes, for consistence.
> >>>
> >
> > as same as max rx pkt len, no?
> >
> >> - What do you think setting 'max_lro_pkt_size' config value to
> >> what PMD provided if application doesn't provide it?
> > Same answers as above.
> >
>
> If application doesn't care the value, as it has been till now, and
> not provided explicit 'max_lro_pkt_size', why not ethdev level use
> the value provided by PMD instead of failing?
> >>>
> >>> Again, same question we can ask on max rx pkt len.
> >>>
> >>> Looks like the packet size is very important value which should be
> >>> set by
> >> the application.
> >>>
> >>> Previous applications have no option to configure it, so they
> >>> haven't
> >> configure it, (probably cover it somehow) I think it is our miss to
> >> supply this info.
> >>>
> >>> Let's do it in same way as we do max rx pkt len (as this patch main idea).
> >>> Later, we can change both to other meaning.
> >>>
> >>
> >> I think it is not a good reason to introduce a new mandatory config
> >> option for application because of 'max_rx_pkt_len' does it.
> >
> > It is mandatory only if LRO offload is configured.
> >
> >> Will it work, if:
> >> - If application doesn't provide this
Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet size
Hi Konstantin
From: Ananyev, Konstantin
> Sent: Friday, November 8, 2019 6:29 PM
> To: Dekel Peled ; Matan Azrad
> ; Yigit, Ferruh ; Mcnamara,
> John ; Kovacevic, Marko
> ; nhor...@tuxdriver.com;
> ajit.khapa...@broadcom.com; somnath.ko...@broadcom.com; Burakov,
> Anatoly ; xuanziya...@huawei.com;
> cloud.wangxiao...@huawei.com; zhouguoy...@huawei.com; Lu, Wenzhuo
> ; Shahaf Shuler ; Slava
> Ovsiienko ; rm...@marvell.com;
> shsha...@marvell.com; maxime.coque...@redhat.com; Bie, Tiwei
> ; Wang, Zhihong ;
> yongw...@vmware.com; Thomas Monjalon ;
> arybche...@solarflare.com; Wu, Jingjing ;
> Iremonger, Bernard
> Cc: dev@dpdk.org
> Subject: RE: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO
> packet size
>
>
> > >
> > >
> > > > > > > On 11/7/2019 12:35 PM, Dekel Peled wrote:
> > > > > > > > @@ -1266,6 +1286,18 @@ struct rte_eth_dev *
> > > > > > > >
> > > > > > > RTE_ETHER_MAX_LEN;
> > > > > > > > }
> > > > > > > >
> > > > > > > > + /*
> > > > > > > > +* If LRO is enabled, check that the maximum
> > > aggregated
> > > > > > > packet
> > > > > > > > +* size is supported by the configured device.
> > > > > > > > +*/
> > > > > > > > + if (dev_conf->rxmode.offloads &
> > > > > > > DEV_RX_OFFLOAD_TCP_LRO) {
> > > > > > > > + ret = check_lro_pkt_size(
> > > > > > > > + port_id, dev_conf-
> > > > > > > > rxmode.max_lro_pkt_size,
> > > > > > > > + dev_info.max_lro_pkt_size);
> > > > > > > > + if (ret != 0)
> > > > > > > > + goto rollback;
> > > > > > > > + }
> > > > > > > > +
> > > > > > >
> > > > > > > This check forces applications that enable LRO to
> > > > > > > provide
> > > > > > > >> 'max_lro_pkt_size'
> > > > > > > config value.
> > > > > > > >>>
> > > > > > > >>> Yes.(we can break an API, we noticed it)
> > > > > > > >>
> > > > > > > >> I am not talking about API/ABI breakage, that part is OK.
> > > > > > > >> With this check, if the application requested LRO offload
> > > > > > > >> but not provided 'max_lro_pkt_size' value, device
> > > > > > > >> configuration will
> > > fail.
> > > > > > > >>
> > > > > > > > Yes
> > > > > > > >> Can there be a case application is good with whatever the
> > > > > > > >> PMD can support as max?
> > > > > > > > Yes can be - you know, we can do everything we want but it
> > > > > > > > is better to be
> > > > > > > consistent:
> > > > > > > > Due to the fact of Max rx pkt len field is mandatory for
> > > > > > > > JUMBO offload, max
> > > > > > > lro pkt len should be mandatory for LRO offload.
> > > > > > > >
> > > > > > > > So your question is actually why both, non-lro packets and
> > > > > > > > LRO packets max
> > > > > > > size are mandatory...
> > > > > > > >
> > > > > > > >
> > > > > > > > I think it should be important values for net applications
> > > management.
> > > > > > > > Also good for mbuf size managements.
> > > > > > > >
> > > > > > > >>>
> > > > > > > - Why it is mandatory now, how it was working before if
> > > > > > > it is mandatory value?
> > > > > > > >>>
> > > > > > > >>> It is the same as max_rx_pkt_len which is mandatory for
> > > > > > > >>> jumbo frame
> > > > > > > >> offload.
> > > > > > > >>> So now, when the user configures a LRO offload he must
> > > > > > > >>> to set max lro pkt
> > > > > > > >> len.
> > > > > > > >>> We don't want to confuse the user here with the max rx
> > > > > > > >>> pkt len
> > > > > > > >> configurations and behaviors, they should be with same logic.
> > > > > > > >>>
> > > > > > > >>> This parameter defines well the LRO behavior.
> > > > > > > >>> Before this, each PMD took its own interpretation to
> > > > > > > >>> what should be the
> > > > > > > >> maximum size for LRO aggregated packets.
> > > > > > > >>> Now, the user must say what is his intension, and the
> > > > > > > >>> ethdev can limit it
> > > > > > > >> according to the device capability.
> > > > > > > >>> By this way, also, the PMD can organize\optimize its
> > > > > > > >>> data-path
> > > more.
> > > > > > > >>> Also, the application can create different mempools for
> > > > > > > >>> LRO queues to
> > > > > > > >> allow bigger packet receiving for LRO traffic.
> > > > > > > >>>
> > > > > > > - What happens if PMD doesn't provide
> > > > > > > 'max_lro_pkt_size', so it is
> > > > > '0'?
> > > > > > > >>> Yes, you can see the feature description Dekel added.
> > > > > > > >>> This patch also updates all the PMDs support an LRO for
> > > > > > > >>> non-0
> > > value.
> > > > > > > >>
> > > > > > > >> Of course I can see the updates Matan, my point is "What
> > > > > > > >> happens if PMD doesn't provide 'max_lro_pkt_size'",
> > > > > > > >> 1) There is no check for it right, so it is acceptable?
> > > > > > > >
> > > > > > > > There is check.
> > > > > > > > If the capability is 0, any non-zero conf
Re: [dpdk-dev] [PATCH 0/3] Add scanning for experimental symbols to meson
09/10/2019 10:17, Luca Boccassi: > On Tue, 2019-10-08 at 15:36 +0100, Bruce Richardson wrote: > > The meson builds were missing support for scanning experimental > > symbols > > in the .o/.a files and matching that against those tagged as > > experimental in the version file. This set adds that missing support. > > > > Bruce Richardson (3): > > check-experimental-syms: remove use of environmental var > > lib: add experimental symbols check to meson build > > drivers: process shared lib link dependencies as for libs > > > > Series-acked-by: Luca Boccassi Applied, thanks
