From: "Leif Lindholm" <quic_llindhol@quicinc.com>
To: <devel@edk2.groups.io>, <mike.maslenkin@gmail.com>,
Igor Kulchytskyy <igork@ami.com>
Cc: Abner Chang <abner.chang@amd.com>, Nickle Wang <nicklew@nvidia.com>
Subject: Re: [edk2-devel] [PATCH v5 2/2] RedfishPkg: RedfishDiscoverDxe: Optimize the Redfish Discover flow
Date: Thu, 16 Nov 2023 12:14:54 +0000 [thread overview]
Message-ID: <3ab53d06-fdcb-4a7b-a96d-4568e7219182@quicinc.com> (raw)
In-Reply-To: <CAL77WPD9=bfJ32i2-TJ6HgWZyk05+2ivRSAyP0heBSjQdyasaA@mail.gmail.com>
On 2023-11-15 18:27, Mike Maslenkin wrote:
> On Wed, Nov 15, 2023 at 4:52 PM Igor Kulchytskyy <igork@ami.com> wrote:
>>
>> Hello Leif and Mike,
>> Let me try to explain the idea of the filtering IP.
>> That filtering should work only if we know exactly that IP is IPv4 or IPv6 in SMBIOS Type 42.
> Hm. I've already composed a reply below, but then a returned to this
> statement...
>
> Is this a difference in condition between v3 and v5? I came to the
> conclusion that at the place we are discussing
> SMBIOS table 42h can be absent because
> PlatformHostInterfaceInformationReady hasn't been called yet,
> so REDFISH_HOST_INTERFACE_HOST_IP_ADDRESS_FORMAT_UNKNOWN is expected.
>
>
>> And it just helping to reduce the work in case we know the exact type of IP, which supposed to be used in BIOS BMC communication.
>> In that case there is no need to build network interface for the unused IP Type.
>> On some systems IP address could be dynamic and we will not be able to know the version of IP from SMBIOS.
>> If you see I check HostIpAssignmentType in GetHiIpProtocolType function. And return IP type UNKNOWN if it is not static.
>> If we get an unknown IP type, we should not return from BuildupNetworkInterface function, but just proceed and build the network interface for all IPs.
>> So, later Redfish Discover driver can find the right one.
>> Based on this logic I'm going to prepare the patch v6.
>> Thank you,
>> Igor
>
> Agree.. I was focused on edk2 implementation of
> RedfishPlatformHostInterfaceLib and PlatformHostInterfaceBmcUsbNicLib
> where HostIpAddressFormat is specified (hardcoded). I guess
> HostIpAddressFormat as well as SMBIOS table 42h must be available
> by the time RedfishServiceAcquireService()->DiscoverRedfishHostInterface()
> call, while it might be not available at the moment
> RedfishDiscoverDriverBindingStart()->BuildupNetworkInterface(). So,
> condition from v3 looks correct to me.
>
> My main concern was introduction of defines. Those don't look great.
> Those are huge (it even doesn't fit into the screen) and misleading a
> bit.
> For example:
> +#define MAC_COMPARE(ThisNetworkInterface, TargetNetworkInterface)
> (CompareMem ((VOID *)&ThisNetworkInterface->MacAddress,
> &TargetNetworkInterface->MacAddress,
> ThisNetworkInterface->HwAddressSize))
>
> The proposed variant is equal to #define MAC_COMPARE(A, B)
> (CompareMem ((VOID *)&ThisNetworkInterface->MacAddress,
> &TargetNetworkInterface->MacAddress,
> ThisNetworkInterface->HwAddressSize)), i.e a bit useless.
>
> I would expect it could be declared at least as:
> #define MAC_COMPARE(This, Target) CompareMem ((VOID
> *)&(This)->MacAddress, &(Target)->MacAddress, (This)->HwAddressSize)
> I.e define should really replace some arguments also reducing the line length.
>
> BTW: there is a place in ValidateTargetNetworkInterface() where
> CompareMem can be replaced with MAC_COMPARE too.
>
> Also, I found IP6_LINK_EQUAL(Mac1, Mac2) define, that is unused in
> edk2. But according to that one, please consider moving "== 0" check
> to #define declaration.
> But I do not think this macro is required at all, because there are 5
> MAC compares left in this module. So, it just brings some
> inconsistency.
>
> Agreed that static helper function would be the best.
>
> Leif, do you expect something like this?
> STATIC
> BOOLEAN
> FilterInterface (
> IN NETWORK_INTERFACE_PROTOCOL_TYPE ProtocolType,
> IN UINT8 HostIpAddressFormat
> )
> {
> // This is based on v5, but according to the comments above
> // v3 is correct as it allows
> REDFISH_HOST_INTERFACE_HOST_IP_ADDRESS_FORMAT_UNKNOWN
>
> if (ProtocolType == ProtocolTypeTcp4) {
> return IpType != REDFISH_HOST_INTERFACE_HOST_IP_ADDRESS_FORMAT_IP4;
> } else if (ProtocolType == ProtocolTypeTcp6) {
> return IpType != REDFISH_HOST_INTERFACE_HOST_IP_ADDRESS_FORMAT_IP6;
> }
Yes, this looks ideal.
> return false;
Although this should be FALSE (upper-case).
> }
>
> and then::
>
> // Get IP Type to filter out unnecessary network protocol if possible
> IpType = GetHiIpProtocolType ();
>
> for (Index = 0; Index < ListCount; Index++) {
> // Check IP Type and skip an unnecessary network protocol if does not match
> if (FilterInterface (gRequiredProtocol[Index].ProtocolType, IpType)) {
This gives us a big but still readable chunk here, and much neater tests
in the helper than they *could* be either in place or in macros.
> continue;
> }
Ship it.
/
Leif
> Regards,
> Mike.
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#111314): https://edk2.groups.io/g/devel/message/111314
Mute This Topic: https://groups.io/mt/102584140/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/leave/12367111/7686176/1913456212/xyzzy [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
next prev parent reply other threads:[~2023-11-16 12:15 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-14 14:28 [edk2-devel] [PATCH v5 2/2] RedfishPkg: RedfishDiscoverDxe: Optimize the Redfish Discover flow Igor Kulchytskyy via groups.io
2023-11-14 14:29 ` Chang, Abner via groups.io
2023-11-14 17:26 ` Leif Lindholm
2023-11-14 18:57 ` Igor Kulchytskyy via groups.io
2023-11-14 23:52 ` Mike Maslenkin
2023-11-15 1:19 ` Chang, Abner via groups.io
2023-11-15 1:21 ` Igor Kulchytskyy via groups.io
2023-11-15 3:55 ` Chang, Abner via groups.io
2023-11-15 10:59 ` edk2-stable202311 Code freeze process violation " Leif Lindholm
2023-11-15 11:07 ` Chang, Abner via groups.io
2023-11-15 11:54 ` Chang, Abner via groups.io
2023-11-15 17:28 ` Michael D Kinney
2023-11-16 0:55 ` 回复: " gaoliming via groups.io
2023-11-15 10:55 ` Leif Lindholm
2023-11-15 12:01 ` Leif Lindholm
2023-11-15 13:51 ` Igor Kulchytskyy via groups.io
2023-11-15 18:27 ` Mike Maslenkin
2023-11-15 18:36 ` Igor Kulchytskyy via groups.io
2023-11-15 19:25 ` Mike Maslenkin
2023-11-15 19:36 ` Igor Kulchytskyy via groups.io
2023-11-16 12:14 ` Leif Lindholm [this message]
2023-11-16 12:23 ` Igor Kulchytskyy via groups.io
2023-11-16 12:25 ` Leif Lindholm
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3ab53d06-fdcb-4a7b-a96d-4568e7219182@quicinc.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox