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 1CDAC43D54; Tue, 26 Mar 2024 14:47:49 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0BD3440265; Tue, 26 Mar 2024 14:47:49 +0100 (CET) Received: from mail-pj1-f42.google.com (mail-pj1-f42.google.com [209.85.216.42]) by mails.dpdk.org (Postfix) with ESMTP id 089BA40E09 for ; Tue, 26 Mar 2024 14:47:46 +0100 (CET) Received: by mail-pj1-f42.google.com with SMTP id 98e67ed59e1d1-29de4c33441so4015598a91.1 for ; Tue, 26 Mar 2024 06:47:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; t=1711460866; x=1712065666; 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=D8v94+UHeoslm85q6KfP/MUwWI3oGPtEo2xjfyyhnyU=; b=FvFoyUw2Rn3OX5LuAzbGARoJqE3nRyrR8mL7MsXF3+AsyR36dyKMVmSMjxLe47pwaX m7WRONcwPjq9/z9iBJs1QQT18psIQOrAIBtA9XjoQKLpi1wcnJd/thshqFTviO3XAVGE W1SqfoRF/Jpsuyar/7dBbHmNlaUL7NST+urCk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711460866; x=1712065666; 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=D8v94+UHeoslm85q6KfP/MUwWI3oGPtEo2xjfyyhnyU=; b=Z6ImfXIc8TP2/STeMABKP+drYqVTCL7XGZq9YGA1H9um0xMd/sbih73L87ct97ug9k S7vb21tFXawCcNwHCf8Em8UuMHFPNK+hPmzyjYAES3pCiKKHzLtNzM0AEQq2hspS0cmx X4gIuZ4j9qklYRK40xUFDD2czKVVr752C1bWEnLFToW1eCtk1gfltDywHXIC+1zUrKOk R/mpwIllXbvdE13UsAujgqo3zHfVMJW3LZrxezO4gv4BIMiFegxvjoUGFKtrwRFs6sHR dTGmN6ssWUwqBsLg6oqY+AmEY5e90Sw5fBHLr4LKaJBbxV6bVFPVnKepKYROwlLbER7Z T+zQ== X-Forwarded-Encrypted: i=1; AJvYcCUk9wxFcd8YuS0O6b7FfeVtLOhVGJHXHInpDI2d6QmBCa1I5QK+SjoCLdEoYNJYTF1b9Y3QBba6R80PZDM= X-Gm-Message-State: AOJu0Yz4rB0eXaWmzU8nVA5QqtJA7Cl6dtZIgnmrp8DMLhuGPU/RaEu1 Gq0Jt0btvONoLoPeOPcGqEGag24Zuyuytl9g8EBKauJnDurCBN1dlhZx1P0b5v4prpESE5aLld6 dM4Verp48aUxwqCA5iZtUfcdmhZy1dcwLwnv4 X-Google-Smtp-Source: AGHT+IEASYcnmmPqJiM9Wbje9mbNZ8dXYf5ZGJPWWooJZ6fnRp1E/nIaMyrOWnTpOFv+9+GmZtWHkK9ApPTlDyWmHMw= X-Received: by 2002:a17:90a:ee42:b0:29c:403b:ea2e with SMTP id bu2-20020a17090aee4200b0029c403bea2emr7192448pjb.49.1711460865906; Tue, 26 Mar 2024 06:47:45 -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: Ajit Khaparde Date: Tue, 26 Mar 2024 06:47:28 -0700 Message-ID: Subject: Re: [PATCH v2 1/6] ethdev: support setting lanes To: "lihuisong (C)" Cc: Thomas Monjalon , huangdengdui , Damodharam Ammepalli , 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="000000000000fd60d90614908883" 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 --000000000000fd60d90614908883 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Gbps */ > >>>>>> -#define RTE_ETH_LINK_SPEED_200G RTE_BIT32(15) /**< 200 Gbps */ > >>>>>> -#define RTE_ETH_LINK_SPEED_400G RTE_BIT32(16) /**< 400 Gbps */ > >>>>>> +#define RTE_ETH_LINK_SPEED_10G RTE_BIT32(8) /**< 10 G= bps */ > >>>>>> +#define RTE_ETH_LINK_SPEED_20G RTE_BIT32(9) /**< 20 G= bps 2lanes */ > >>>>>> +#define RTE_ETH_LINK_SPEED_25G RTE_BIT32(10) /**< 25 G= bps */ > >>>>>> +#define RTE_ETH_LINK_SPEED_40G RTE_BIT32(11) /**< 40 G= bps 4lanes */ > >>>>>> +#define RTE_ETH_LINK_SPEED_50G RTE_BIT32(12) /**< 50 G= bps */ > >>>>>> +#define RTE_ETH_LINK_SPEED_56G RTE_BIT32(13) /**< 56 G= bps 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 G= bps 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 bitmask= . > >>>>> > >>>> 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 and la= nes. > >>>> > >>>> 2. For the PHY, When the physical layer capability is configured thr= ough the MDIO, > >>>> the speed and lanes are also coupled. > >>>> For example: > >>>> Table 45=E2=80=937=E2=80=94PMA/PMD control 2 register bit definition= s[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 vers= ion. > >>>> When the driver does not support the lanes setting, the code does no= t 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 difficult 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 specified > >> speed. This is determined by releated specification. > >> If we add a separate API for speed lanes, it probably is hard to check > >> 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 speed > capabilities. > > > > There is no problem providing a function to get the number of PHY lanes= . > > 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 follow po= ints: > >> 1) user don't know what lanes should or can be set for a specified spe= ed > >> on one NIC. > > This is about capabilities. > > Can we say a HW will support a maximum number of PHY lanes in general? > > We may need to associate the maximum speed per lane? > > Do we really need to associate PHY lane and PHY speed numbers for capab= ilities? > 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 user > is not supported on a fixed speed by PMD. > So ethdev layer should limit the avaiable lane number based on a fixed > speed. ethdev layer has generally been opaque. We should keep it that way. 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 does. > Agreed. > > > >> [1] https://patchwork.dpdk.org/project/dpdk/list/?series=3D31606 > > > > > > . --000000000000fd60d90614908883 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIQdgYJKoZIhvcNAQcCoIIQZzCCEGMCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg3NMIIFDTCCA/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/ XzCCBVUwggQ9oAMCAQICDAzZWuPidkrRZaiw2zANBgkqhkiG9w0BAQsFADBbMQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTExMC8GA1UEAxMoR2xvYmFsU2lnbiBHQ0MgUjMg UGVyc29uYWxTaWduIDIgQ0EgMjAyMDAeFw0yMjA5MTAwODE4NDVaFw0yNTA5MTAwODE4NDVaMIGW MQswCQYDVQQGEwJJTjESMBAGA1UECBMJS2FybmF0YWthMRIwEAYDVQQHEwlCYW5nYWxvcmUxFjAU BgNVBAoTDUJyb2FkY29tIEluYy4xHDAaBgNVBAMTE0FqaXQgS3VtYXIgS2hhcGFyZGUxKTAnBgkq hkiG9w0BCQEWGmFqaXQua2hhcGFyZGVAYnJvYWRjb20uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEArZ/Aqg34lMOo2BabvAa+dRThl9OeUUJMob125dz+jvS78k4NZn1mYrHu53Dn YycqjtuSMlJ6vJuwN2W6QpgTaA2SDt5xTB7CwA2urpcm7vWxxLOszkr5cxMB1QBbTd77bXFuyTqW jrer3VIWqOujJ1n+n+1SigMwEr7PKQR64YKq2aRYn74ukY3DlQdKUrm2yUkcA7aExLcAwHWUna/u pZEyqKnwS1lKCzjX7mV5W955rFsFxChdAKfw0HilwtqdY24mhy62+GeaEkD0gYIj1tCmw9gnQToc K+0s7xEunfR9pBrzmOwS3OQbcP0nJ8SmQ8R+reroH6LYuFpaqK1rgQIDAQABo4IB2zCCAdcwDgYD VR0PAQH/BAQDAgWgMIGjBggrBgEFBQcBAQSBljCBkzBOBggrBgEFBQcwAoZCaHR0cDovL3NlY3Vy ZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQvZ3NnY2NyM3BlcnNvbmFsc2lnbjJjYTIwMjAuY3J0MEEG CCsGAQUFBzABhjVodHRwOi8vb2NzcC5nbG9iYWxzaWduLmNvbS9nc2djY3IzcGVyc29uYWxzaWdu MmNhMjAyMDBNBgNVHSAERjBEMEIGCisGAQQBoDIBKAowNDAyBggrBgEFBQcCARYmaHR0cHM6Ly93 d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wCQYDVR0TBAIwADBJBgNVHR8EQjBAMD6gPKA6 hjhodHRwOi8vY3JsLmdsb2JhbHNpZ24uY29tL2dzZ2NjcjNwZXJzb25hbHNpZ24yY2EyMDIwLmNy bDAlBgNVHREEHjAcgRphaml0LmtoYXBhcmRlQGJyb2FkY29tLmNvbTATBgNVHSUEDDAKBggrBgEF BQcDBDAfBgNVHSMEGDAWgBSWM9HmWBdbNHWKgVZk1b5I3qGPzzAdBgNVHQ4EFgQUbrcTuh0mr2qP xYdtyDgFeRIiE/gwDQYJKoZIhvcNAQELBQADggEBALrc1TljKrDhXicOaZlzIQyqOEkKAZ324i8X OwzA0n2EcPGmMZvgARurvanSLD3mLeeuyq1feCcjfGM1CJFh4+EY7EkbFbpVPOIdstSBhbnAJnOl aC/q0wTndKoC/xXBhXOZB8YL/Zq4ZclQLMUO6xi/fFRyHviI5/IrosdrpniXFJ9ukJoOXtvdrEF+ KlMYg/Deg9xo3wddCqQIsztHSkR4XaANdn+dbLRQpctZ13BY1lim4uz5bYn3M0IxyZWkQ1JuPHCK aRJv0SfR88PoI4RB7NCEHqFwARTj1KvFPQi8pK/YISFydZYbZrxQdyWDidqm4wSuJfpE6i0cWvCd u50xggJtMIICaQIBATBrMFsxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNh MTEwLwYDVQQDEyhHbG9iYWxTaWduIEdDQyBSMyBQZXJzb25hbFNpZ24gMiBDQSAyMDIwAgwM2Vrj 4nZK0WWosNswDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIJ3MDhcp0sRf8ZOtH8ed F0cE68R9jsAZPVX4EVeXXm8wMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTI0MDMyNjEzNDc0NlowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsG CWCGSAFlAwQCATANBgkqhkiG9w0BAQEFAASCAQB0wcJ8dKzYROJgP6QBCbXLQ5uAjb855U6UVzs8 Mag/X6E2cb8RpCLQLi1OeegQHuzifYh3E8PlqDlSRCc5d9qZWv8jDpDS+NrWUPfWUkTlHYoyi9IV F6SHn7BKFOqkJtFtFazADgjEEMQ2SukSkBi0ERq97Cz1tcS00LSXwYyj4qMI6eEbCWdUv6QbkNFj N8rDi63/+oDCdYPdefLweJ591SSxJ125a0ciqiQcPxbLgOBjN0/D/OBYiLrYlNZwC7HpmNd3w84B NqvJz6KrWcj7/trM3SArWyOj/4zK+W1Vx3JHBttBiox2ZR81A7z7T4SnmKS36eIHTaykgk6bEPNL --000000000000fd60d90614908883--