From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id C2D3143D57; Tue, 26 Mar 2024 19:21:20 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A8BE140E72; Tue, 26 Mar 2024 19:21:20 +0100 (CET) Received: from mail-lj1-f172.google.com (mail-lj1-f172.google.com [209.85.208.172]) by mails.dpdk.org (Postfix) with ESMTP id 25068402DA for ; Tue, 26 Mar 2024 19:21:19 +0100 (CET) Received: by mail-lj1-f172.google.com with SMTP id 38308e7fff4ca-2d687da75c4so67621831fa.0 for ; Tue, 26 Mar 2024 11:21:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; t=1711477278; x=1712082078; darn=dpdk.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=CPcD5zvERtFLp/Om2TYRWaQHSmwraPnGLWLcA0Lbom4=; b=C/x8C23oOJNl6OcZqA3q3hl6+FrXGXpWdtceq/NYfY7hwaqsDbvxAXUttkiJ0lPjdT WOzrd+fKjGsom2OxsrnxZGTKJfpt93OR8QnufYlZJPihfQnJoxpPmkB7IZgVmVick3aI d5eAhQMwhzsplVCXskqUByDvr7zdJcnFoLbRg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711477278; x=1712082078; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=CPcD5zvERtFLp/Om2TYRWaQHSmwraPnGLWLcA0Lbom4=; b=wn0IbbKWEh1zbgFDSbOD5aQ9dboiEnG227lfYowoskbtR90Rv/GwTtlqM5pmPiXAau WVgFQX87OoTTSlO9gjLzv85/DZdt/mHevPTzkyv7T6LjCDLQk6kb5o9XINE7kjEXnrMd a0UV3Q16p6GVmCagvYqX5SW6PlfPKokLNV2nNWwMWxlh7JCWBRcuoko1G/w/NqiVBg0e zoWxgfuPgSe05sCyk+HwbSmzrXf/MqDeu9Q6P2pUzVErz7ha4S473Lhbum4pfm6E+hlx zZQHni616Ql4bNIQ+SATS0l+3wHYTd4QBUO4cRTJ+tHIwLqcqRu4kSS2WVaPMnKlr1b4 Mtgw== X-Forwarded-Encrypted: i=1; AJvYcCWi48u8syd6guFIzM6kkeJxDkhvd5dq8hCf+nSkf9LYiIpT3hr0wiN3fRoR/IWoiSABOfVkrwmcDGABWoc= X-Gm-Message-State: AOJu0YxzthZCMuz9q2yaUJad+BHsgRdCKbhWQaQyQj+hMjS9m4Y3sscX PQnqkiMxf6eLkGy9upJdJq5JxUov+7xvEhOYM3VfO/TY3dJ7bauV9hShvC37/DN9feC1/6mw5n+ mekhAlCmvplXkhdAoqFRtUaQMnQY42E78BRpMgqZKMdlFRp2y+oc2Lt9fDYez9jpxiZSwV0W9OJ 34GkFp X-Google-Smtp-Source: AGHT+IFtC1PcW1pWHC3zcJHgyebmJljnmYVQ/6DiP5XFyxSnF+0lL+jDyz+3KmCR7bUGhl7KyBtHS734fIBM6xR/FR4= X-Received: by 2002:a2e:88cb:0:b0:2d6:f5db:4d6e with SMTP id a11-20020a2e88cb000000b002d6f5db4d6emr148760ljk.40.1711477278391; Tue, 26 Mar 2024 11:21:18 -0700 (PDT) MIME-Version: 1.0 References: <20240312075238.3319480-4-huangdengdui@huawei.com> <3325989.AxlXzFCzgd@thomas> <68ee0a54-c0b4-293c-67ee-efed8964c33b@huawei.com> <3628913.0YcMNavOfZ@thomas> In-Reply-To: From: Damodharam Ammepalli Date: Tue, 26 Mar 2024 11:21:05 -0700 Message-ID: Subject: Re: [PATCH v2 1/6] ethdev: support setting lanes To: Ajit Khaparde Cc: "lihuisong (C)" , Thomas Monjalon , huangdengdui , roretzla@linux.microsoft.com, dev@dpdk.org, ferruh.yigit@amd.com, aman.deep.singh@intel.com, yuying.zhang@intel.com, andrew.rybchenko@oktetlabs.ru, stephen@networkplumber.org, jerinjacobk@gmail.com, liuyonglong@huawei.com, fengchengwen@huawei.com, haijie1@huawei.com Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000003f98eb0614945b1a" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org --0000000000003f98eb0614945b1a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Mar 26, 2024 at 11:12=E2=80=AFAM Ajit Khaparde wrote: > > On Tue, Mar 26, 2024 at 6:47=E2=80=AFAM Ajit Khaparde > wrote: > > > > On Tue, Mar 26, 2024 at 4:15=E2=80=AFAM lihuisong (C) wrote: > > > > > > > > > =E5=9C=A8 2024/3/26 18:30, Thomas Monjalon =E5=86=99=E9=81=93: > > > > 26/03/2024 02:42, lihuisong (C): > > > >> =E5=9C=A8 2024/3/25 17:30, Thomas Monjalon =E5=86=99=E9=81=93: > > > >>> 25/03/2024 07:24, huangdengdui: > > > >>>> On 2024/3/22 21:58, Thomas Monjalon wrote: > > > >>>>> 22/03/2024 08:09, Dengdui Huang: > > > >>>>>> -#define RTE_ETH_LINK_SPEED_10G RTE_BIT32(8) /**< 10 Gbps= */ > > > >>>>>> -#define RTE_ETH_LINK_SPEED_20G RTE_BIT32(9) /**< 20 Gbps= */ > > > >>>>>> -#define RTE_ETH_LINK_SPEED_25G RTE_BIT32(10) /**< 25 Gbps= */ > > > >>>>>> -#define RTE_ETH_LINK_SPEED_40G RTE_BIT32(11) /**< 40 Gbps= */ > > > >>>>>> -#define RTE_ETH_LINK_SPEED_50G RTE_BIT32(12) /**< 50 Gbps= */ > > > >>>>>> -#define RTE_ETH_LINK_SPEED_56G RTE_BIT32(13) /**< 56 Gbps= */ > > > >>>>>> -#define RTE_ETH_LINK_SPEED_100G RTE_BIT32(14) /**< 100 Gbp= s */ > > > >>>>>> -#define RTE_ETH_LINK_SPEED_200G RTE_BIT32(15) /**< 200 Gbp= s */ > > > >>>>>> -#define RTE_ETH_LINK_SPEED_400G RTE_BIT32(16) /**< 400 Gbp= s */ > > > >>>>>> +#define RTE_ETH_LINK_SPEED_10G RTE_BIT32(8) /**< = 10 Gbps */ > > > >>>>>> +#define RTE_ETH_LINK_SPEED_20G RTE_BIT32(9) /**< = 20 Gbps 2lanes */ > > > >>>>>> +#define RTE_ETH_LINK_SPEED_25G RTE_BIT32(10) /**< = 25 Gbps */ > > > >>>>>> +#define RTE_ETH_LINK_SPEED_40G RTE_BIT32(11) /**< = 40 Gbps 4lanes */ > > > >>>>>> +#define RTE_ETH_LINK_SPEED_50G RTE_BIT32(12) /**< = 50 Gbps */ > > > >>>>>> +#define RTE_ETH_LINK_SPEED_56G RTE_BIT32(13) /**< = 56 Gbps 4lanes */ > > > >>>>>> +#define RTE_ETH_LINK_SPEED_100G RTE_BIT32(14) /**< = 100 Gbps */ > > > >>>>>> +#define RTE_ETH_LINK_SPEED_200G RTE_BIT32(15) /**< = 200 Gbps 4lanes */ > > > >>>>>> +#define RTE_ETH_LINK_SPEED_400G RTE_BIT32(16) /**< = 400 Gbps 4lanes */ > > > >>>>>> +#define RTE_ETH_LINK_SPEED_10G_4LANES RTE_BIT32(17) /**<= 10 Gbps 4lanes */ > > > >>>>>> +#define RTE_ETH_LINK_SPEED_50G_2LANES RTE_BIT32(18) /**< = 50 Gbps 2 lanes */ > > > >>>>>> +#define RTE_ETH_LINK_SPEED_100G_2LANES RTE_BIT32(19) /**< = 100 Gbps 2 lanes */ > > > >>>>>> +#define RTE_ETH_LINK_SPEED_100G_4LANES RTE_BIT32(20) /**< = 100 Gbps 4lanes */ > > > >>>>>> +#define RTE_ETH_LINK_SPEED_200G_2LANES RTE_BIT32(21) /**< = 200 Gbps 2lanes */ > > > >>>>>> +#define RTE_ETH_LINK_SPEED_400G_8LANES RTE_BIT32(22) /**< = 400 Gbps 8lanes */ > > > >>>>> I don't think it is a good idea to make this more complex. > > > >>>>> It brings nothing as far as I can see, compared to having speed= and lanes separated. > > > >>>>> Can we have lanes information a separate value? no need for bit= mask. > > > >>>>> > > > >>>> Hi,Thomas, Ajit, roretzla, damodharam > > > >>>> > > > >>>> I also considered the option at the beginning of the design. > > > >>>> But this option is not used due to the following reasons: > > > >>>> 1. For the user, ethtool couples speed and lanes. > > > >>>> The result of querying the NIC capability is as follows: > > > >>>> Supported link modes: > > > >>>> 100000baseSR4/Full > > > >>>> 100000baseSR2/Full > > > >>>> The NIC capability is configured as follows: > > > >>>> ethtool -s eth1 speed 100000 lanes 4 autoneg off > > > >>>> ethtool -s eth1 speed 100000 lanes 2 autoneg off > > > >>>> > > > >>>> Therefore, users are more accustomed to the coupling of speed an= d lanes. > > > >>>> > > > >>>> 2. For the PHY, When the physical layer capability is configured= through the MDIO, > > > >>>> the speed and lanes are also coupled. > > > >>>> For example: > > > >>>> Table 45=E2=80=937=E2=80=94PMA/PMD control 2 register bit defini= tions[1] > > > >>>> PMA/PMD type selection > > > >>>> 1 0 0 1 0 1 0 =3D 100GBASE-SR2 PMA/PMD > > > >>>> 0 1 0 1 1 1 1 =3D 100GBASE-SR4 PMA/PMD > > > >>>> > > > >>>> Therefore, coupling speeds and lanes is easier to understand. > > > >>>> And it is easier for the driver to report the support lanes. > > > >>>> > > > >>>> In addition, the code implementation is compatible with the old = version. > > > >>>> When the driver does not support the lanes setting, the code doe= s not need to be modified. > > > >>>> > > > >>>> So I think the speed and lanes coupling is better. > > > >>> I don't think so. > > > >>> You are mixing hardware implementation, user tool, and API. > > > >>> Having a separate and simple API is cleaner and not more difficul= t to handle > > > >>> in some get/set style functions. > > > >> Having a separate and simple API is cleaner. It's good. > > > >> But supported lane capabilities have a lot to do with the specifie= d > > > >> speed. This is determined by releated specification. > > > >> If we add a separate API for speed lanes, it probably is hard to c= heck > > > >> the validity of the configuration for speed and lanes. > > > >> And the setting lane API sepparated from speed is not good for > > > >> uniforming all PMD's behavior in ethdev layer. > > > > Please let's be more specific. > > > > There are 3 needs: > > > > - set PHY lane config > > > > - get PHY lane config > > > > - get PHY lane capabilities > > > IMO, this lane capabilities should be reported based on supported spe= ed > > > capabilities. > > > > > > > > There is no problem providing a function to get the number of PHY l= anes. > > > > It is possible to set PHY lanes number after defining a fixed speed= . > > > yes it's ok. > > > > > > > >> The patch[1] is an example for this separate API. > > > >> I think it is not very good. It cannot tell user and PMD the follo= w points: > > > >> 1) user don't know what lanes should or can be set for a specified= speed > > > >> on one NIC. > > > > This is about capabilities. > > > > Can we say a HW will support a maximum number of PHY lanes in gener= al? > > > > We may need to associate the maximum speed per lane? > > > > Do we really need to associate PHY lane and PHY speed numbers for c= apabilities? > > > Personally, it should contain the below releationship at least. > > > speed 10G --> 1lane | 4lane > > > speed 100G --> 2lane | 4lane > > > > Example: if a HW supports 100G-4-lanes and 200G-2-lanes, > > > > may we assume it is also supporting 200G-4-lanes? > > > I think we cannot assume that NIC also support 200G-4-lanes. > > > Beause it has a lot to do with HW design. > > > > > > > >> 2) how should PMD do for a supported lanes in their HW? > > > > I don't understand this question. Please rephrase. > > > I mean that PMD don't know set how many lanes when the lanes from use= r > > > is not supported on a fixed speed by PMD. > > > So ethdev layer should limit the avaiable lane number based on a fixe= d > > > speed. > > > > ethdev layer has generally been opaque. We should keep it that way. > I mis-typed. > %s/opaque/transparent > > > > The PMD should know what the HW supports. > > So it should show the capabilities correctly. Right? > > And if the user provides incorrect settings, it should reject it. > > > > > > > > > >> Anyway, if we add setting speed lanes feature, we must report and = set > > > >> speed and lanes capabilities for user well. > > > >> otherwise, user will be more confused. > > > > Well is not necessarily exposing all raw combinations as ethtool do= es. > > > Agreed. > > > > > > > >> [1] https://patchwork.dpdk.org/project/dpdk/list/?series=3D31606 > > > > > > > > > > > > Our RFC patch's cmdline design is inspired by how ethtool works as it provides carriage return at user choice, which makes it backward compatible for no lanes config also. testpmd does not have that flexibility in the speed command and we resorted to a separate command for lanes and for all other reasons mentioned earlier. 2nd, the lanes validation logic resting place, irrespective of lanes in speed or separate lanes command, like others said, the AutoNegotiation itself should suffice for link train and up. Taking this example, if the link came up at 100G PAM4-112 AN'd, and user for whatever reasons, even others mentioned earlier, may want it to force 100Gb NRZ which is 25G per lane 4, lanes), the user should aware of cmds the tool offers, and the driver can do final validation, for anomalies. In any case, in RFC patch we are doing lanes validation in cmd_validate_lanes(portid_t pid, uint32_t *lanes), that gets populated by hw/driver based on current AN's link up speed and signalling type. Today 400Gig is 4(pam4_56), 8(pam4_112) lanes and in future with a new HW design, it may be 2 x 200Gig lanes, at that time. we don't need to update testpmd, handle it in the driver. Maybe for a new speed 800Gb+, can demand an update to app/lib entries. --=20 This electronic communication and the information and any files transmitted= =20 with it, or attached to it, are confidential and are intended solely for=20 the use of the individual or entity to whom it is addressed and may contain= =20 information that is confidential, legally privileged, protected by privacy= =20 laws, or otherwise restricted from disclosure to anyone else. If you are=20 not the intended recipient or the person responsible for delivering the=20 e-mail to the intended recipient, you are hereby notified that any use,=20 copying, distributing, dissemination, forwarding, printing, or copying of= =20 this e-mail is strictly prohibited. If you received this e-mail in error,= =20 please return the e-mail to the sender, delete it from your computer, and= =20 destroy any printed copy of it. --0000000000003f98eb0614945b1a Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIQhQYJKoZIhvcNAQcCoIIQdjCCEHICAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg3cMIIFDTCCA/WgAwIBAgIQeEqpED+lv77edQixNJMdADANBgkqhkiG9w0BAQsFADBMMSAwHgYD VQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UE AxMKR2xvYmFsU2lnbjAeFw0yMDA5MTYwMDAwMDBaFw0yODA5MTYwMDAwMDBaMFsxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTEwLwYDVQQDEyhHbG9iYWxTaWduIEdDQyBS MyBQZXJzb25hbFNpZ24gMiBDQSAyMDIwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA vbCmXCcsbZ/a0fRIQMBxp4gJnnyeneFYpEtNydrZZ+GeKSMdHiDgXD1UnRSIudKo+moQ6YlCOu4t rVWO/EiXfYnK7zeop26ry1RpKtogB7/O115zultAz64ydQYLe+a1e/czkALg3sgTcOOcFZTXk38e aqsXsipoX1vsNurqPtnC27TWsA7pk4uKXscFjkeUE8JZu9BDKaswZygxBOPBQBwrA5+20Wxlk6k1 e6EKaaNaNZUy30q3ArEf30ZDpXyfCtiXnupjSK8WU2cK4qsEtj09JS4+mhi0CTCrCnXAzum3tgcH cHRg0prcSzzEUDQWoFxyuqwiwhHu3sPQNmFOMwIDAQABo4IB2jCCAdYwDgYDVR0PAQH/BAQDAgGG MGAGA1UdJQRZMFcGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQCAgYKKwYBBAGCNwoDBAYJ KwYBBAGCNxUGBgorBgEEAYI3CgMMBggrBgEFBQcDBwYIKwYBBQUHAxEwEgYDVR0TAQH/BAgwBgEB /wIBADAdBgNVHQ4EFgQUljPR5lgXWzR1ioFWZNW+SN6hj88wHwYDVR0jBBgwFoAUj/BLf6guRSSu TVD6Y5qL3uLdG7wwegYIKwYBBQUHAQEEbjBsMC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC5nbG9i YWxzaWduLmNvbS9yb290cjMwOwYIKwYBBQUHMAKGL2h0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5j b20vY2FjZXJ0L3Jvb3QtcjMuY3J0MDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuZ2xvYmFs c2lnbi5jb20vcm9vdC1yMy5jcmwwWgYDVR0gBFMwUTALBgkrBgEEAaAyASgwQgYKKwYBBAGgMgEo CjA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzAN BgkqhkiG9w0BAQsFAAOCAQEAdAXk/XCnDeAOd9nNEUvWPxblOQ/5o/q6OIeTYvoEvUUi2qHUOtbf jBGdTptFsXXe4RgjVF9b6DuizgYfy+cILmvi5hfk3Iq8MAZsgtW+A/otQsJvK2wRatLE61RbzkX8 9/OXEZ1zT7t/q2RiJqzpvV8NChxIj+P7WTtepPm9AIj0Keue+gS2qvzAZAY34ZZeRHgA7g5O4TPJ /oTd+4rgiU++wLDlcZYd/slFkaT3xg4qWDepEMjT4T1qFOQIL+ijUArYS4owpPg9NISTKa1qqKWJ jFoyms0d0GwOniIIbBvhI2MJ7BSY9MYtWVT5jJO3tsVHwj4cp92CSFuGwunFMzCCA18wggJHoAMC AQICCwQAAAAAASFYUwiiMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9v dCBDQSAtIFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5 MDMxODEwMDAwMFoXDTI5MDMxODEwMDAwMFowTDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENB IC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMJXaQeQZ4Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0E XyTLLkvhYIJG4VKrDIFHcGzdZNHr9SyjD4I9DCuul9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+J J5U4nwbXPsnLJlkNc96wyOkmDoMVxu9bi9IEYMpJpij2aTv2y8gokeWdimFXN6x0FNx04Druci8u nPvQu7/1PQDhBjPogiuuU6Y6FnOM3UEOIDrAtKeh6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTv riBJ/K1AFUjRAjFhGV64l++td7dkmnq/X8ET75ti+w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGj QjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5N UPpjmove4t0bvDANBgkqhkiG9w0BAQsFAAOCAQEAS0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigH M8pr5nS5ugAtrqQK0/Xx8Q+Kv3NnSoPHRHt44K9ubG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmU Y/vcU2hnVj6DuM81IcPJaP7O2sJTqsyQiunwXUaMld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V 14qWtNPeTCekTBtzc3b0F5nCH3oO4y0IrQocLP88q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcy a5QBqJnnLDMfOjsl0oZAzjsshnjJYS8Uuu7bVW/fhO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/ XzCCBWQwggRMoAMCAQICDCNl0xOqjSjPAgmvqjANBgkqhkiG9w0BAQsFADBbMQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTExMC8GA1UEAxMoR2xvYmFsU2lnbiBHQ0MgUjMg UGVyc29uYWxTaWduIDIgQ0EgMjAyMDAeFw0yMjA1MTIxMDAzMjRaFw0yNDA1MTIxMDAzMjRaMIGe MQswCQYDVQQGEwJJTjESMBAGA1UECBMJS2FybmF0YWthMRIwEAYDVQQHEwlCYW5nYWxvcmUxFjAU BgNVBAoTDUJyb2FkY29tIEluYy4xHTAbBgNVBAMTFERhbW9kaGFyYW0gQW1tZXBhbGxpMTAwLgYJ KoZIhvcNAQkBFiFkYW1vZGhhcmFtLmFtbWVwYWxsaUBicm9hZGNvbS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCnRr7ymln4NZVOj87tX9rjEs4b0AmDa3SyoWm18VyAygGjRW2h jYJ1msX0+fIfx1i8lOyzCf7sz5BjcO8+PPnTVQ1qH2ExJMRb7ue3sly+e9KPlcWVTfIbGz/jDOJY NAxVILiHuNhHcAAjlMMtN5GpiJu+l8YpuZ6Fl2iRZpnRTG3MBA3xxsrrbkrC73faiYG1SE9r52Ca aOJ1U4azp3DDv7tK+b5aEJN/TYCGwmIYYF97+Ctk626oQpou/3+RMds6GftV+DbwkyxRA3pQmMtu 7dKd35PfHpujFFtT3AkqXDVQdtN18vs+iZ2uMJyKiZcc33Pqqz6RxKL2sDnr0cbVAgMBAAGjggHi MIIB3jAOBgNVHQ8BAf8EBAMCBaAwgaMGCCsGAQUFBwEBBIGWMIGTME4GCCsGAQUFBzAChkJodHRw Oi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2djY3IzcGVyc29uYWxzaWduMmNhMjAy MC5jcnQwQQYIKwYBBQUHMAGGNWh0dHA6Ly9vY3NwLmdsb2JhbHNpZ24uY29tL2dzZ2NjcjNwZXJz b25hbHNpZ24yY2EyMDIwME0GA1UdIARGMEQwQgYKKwYBBAGgMgEoCjA0MDIGCCsGAQUFBwIBFiZo dHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzAJBgNVHRMEAjAAMEkGA1UdHwRC MEAwPqA8oDqGOGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NnY2NyM3BlcnNvbmFsc2lnbjJj YTIwMjAuY3JsMCwGA1UdEQQlMCOBIWRhbW9kaGFyYW0uYW1tZXBhbGxpQGJyb2FkY29tLmNvbTAT BgNVHSUEDDAKBggrBgEFBQcDBDAfBgNVHSMEGDAWgBSWM9HmWBdbNHWKgVZk1b5I3qGPzzAdBgNV HQ4EFgQUj2udHgCJQQuMhomN9GsD2KsV8pMwDQYJKoZIhvcNAQELBQADggEBAEkcEYhM+FGUXls8 IbdQvX1i+trqwhjSy9sEx7xkF65/4gY9SCOU8P1evTpr0UrixCuvK64g2USSy/StKcb5AUr9fta3 yHCxJNdq03gafRfGOUsc0kj2b+nZjRE/1YtfLTmgxL+NtTrBcLALU3bOoKkz2h1U3QdJzok0QfFH +GGqC2E5Wo5K7FivUYFaDWS9p+4e941vTiAG8acjHZ9kKe2nASN4mo/Tp4JZeTubsngd/fYA29KN 5Zu+40L5dLEKHXcnehtX1mCxP/ObqffGAFXM/mbpyQjZV+gVCEwsJfgJ5HzlNFwWVQhuR4aPTiNw LbL2uJ39Pqh1IaZkikf043QxggJtMIICaQIBATBrMFsxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBH bG9iYWxTaWduIG52LXNhMTEwLwYDVQQDEyhHbG9iYWxTaWduIEdDQyBSMyBQZXJzb25hbFNpZ24g MiBDQSAyMDIwAgwjZdMTqo0ozwIJr6owDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIE IKfeV3m+8kM5L27kNV+sMMnGis9UE2fox52864H1PtV7MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTI0MDMyNjE4MjExOFowaQYJKoZIhvcNAQkPMVwwWjALBglghkgB ZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQow CwYJKoZIhvcNAQEHMAsGCWCGSAFlAwQCATANBgkqhkiG9w0BAQEFAASCAQAJE/OX5/t0+ALvZ13Y /tCgJA4V1GAeRSouV1iVxr0yp6vFh6tFsJOuPVMgkIYYa2FBkbdmEKYWVg/aewmQTaEyniGRCiEj PHWdHeHkLhXh4w6s8T3LJB7OpsbQ2aSVEtndftbaT8DODs4oTOo1IP8La8g+we4yBBr56h7A0m2N WNHr/+yU9dYid6tqwLIb/LhTauLqQ1GTgoxyj5qAcC69IgcjU46X14k7az681/R+Qyu0zcUZRlOk VSPVTVUfqgF5sWazoeY3zJJ8fHUbDomUWPlB8XOJiX3+hy6YOiKO7tVMp7psHw83LUKjFpcCO46B n18zlHOk4rriQYBqPhbw --0000000000003f98eb0614945b1a--