From: "Igor Kulchytskyy via groups.io" <igork=ami.com@groups.io>
To: Leif Lindholm <quic_llindhol@quicinc.com>,
"devel@edk2.groups.io" <devel@edk2.groups.io>,
"mike.maslenkin@gmail.com" <mike.maslenkin@gmail.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: Wed, 15 Nov 2023 13:51:57 +0000 [thread overview]
Message-ID: <BLAPR10MB5185D5F40E4BEA4D091E6856A8B1A@BLAPR10MB5185.namprd10.prod.outlook.com> (raw)
In-Reply-To: <2f8fbb9f-bca8-4771-9178-6f0507ad089e@quicinc.com>
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.
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
-----Original Message-----
From: Leif Lindholm <quic_llindhol@quicinc.com>
Sent: Wednesday, November 15, 2023 7:02 AM
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: [EXTERNAL] Re: [edk2-devel] [PATCH v5 2/2] RedfishPkg: RedfishDiscoverDxe: Optimize the Redfish Discover flow
**CAUTION: The e-mail below is from an external source. Please exercise caution before opening attachments, clicking links, or following guidance.**
On 2023-11-14 23:52, Mike Maslenkin wrote:
> On Tue, Nov 14, 2023 at 9:57 PM Igor Kulchytskyy via groups.io
> <igork=ami.com@groups.io> wrote:
>>
>> Hi Leif,
>> Please see my comments below.
>> Thank you,
>> Igor
>>
>>
>> -----Original Message-----
>> From: Leif Lindholm <quic_llindhol@quicinc.com>
>> Sent: Tuesday, November 14, 2023 12:26 PM
>> To: devel@edk2.groups.io; Igor Kulchytskyy <igork@ami.com>
>> Cc: Abner Chang <abner.chang@amd.com>; Nickle Wang <nicklew@nvidia.com>
>> Subject: [EXTERNAL] Re: [edk2-devel] [PATCH v5 2/2] RedfishPkg: RedfishDiscoverDxe: Optimize the Redfish Discover flow
>>
>>
>> **CAUTION: The e-mail below is from an external source. Please exercise caution before opening attachments, clicking links, or following guidance.**
>>
>> On 2023-11-14 14:28, Igor Kulchytskyy via groups.io wrote:
>>> Filter out the network interfaces which are not supported by
>>> Redfish Host Interface.
>>>
>>> Cc: Abner Chang <abner.chang@amd.com>
>>> Cc: Nickle Wang <nicklew@nvidia.com>
>>> Signed-off-by: Igor Kulchytskyy <igork@ami.com>
>>> ---
>>> RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c | 163 ++++++++++++++------
>>> RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverInternal.h | 6 +
>>> 2 files changed, 120 insertions(+), 49 deletions(-)
>>>
>>> diff --git a/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c
>>> index 0f622e05a9..ae83cd3c97 100644
>>> --- a/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c
>>> +++ b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c
>>
>>
>>> @@ -1601,10 +1681,22 @@ BuildupNetworkInterface (
>>> EFI_REDFISH_DISCOVER_REST_EX_INSTANCE_INTERNAL *RestExInstance;
>>> EFI_TPL OldTpl;
>>> BOOLEAN NewNetworkInterfaceInstalled;
>>> + UINT8 IpType;
>>> + UINTN ListCount;
>>>
>>> + ListCount = (sizeof (gRequiredProtocol) / sizeof (REDFISH_DISCOVER_REQUIRED_PROTOCOL));
>>> NewNetworkInterfaceInstalled = FALSE;
>>> Index = 0;
>>> - do {
>>> +
>>> + // 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 (IS_TCP4_MATCH (IpType) || IS_TCP6_MATCH (IpType)) {
>>
>> The logic of these macros is inverted compared to their names, though.
>>
>> You want this test to read
>> if (!IS_TCP4_MATCH (IpType) && !IS_TCP6_MATCH (IpType)) {
>>
>>> + continue;
>>> + }
>>> +
>>> Status = gBS->OpenProtocol (
>>> // Already in list?
>>> ControllerHandle,
>>
>>> diff --git a/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverInternal.h b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverInternal.h
>>> index 01454acc1d..3093eea0d5 100644
>>> --- a/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverInternal.h
>>> +++ b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverInternal.h
>>> @@ -39,6 +39,12 @@
>>> #define REDFISH_DISCOVER_VERSION 0x00010000
>>> #define EFI_REDFISH_DISCOVER_NETWORK_INTERFACE_TPL TPL_NOTIFY
>>>
>>> +#define MAC_COMPARE(ThisNetworkInterface, TargetNetworkInterface) (CompareMem ((VOID *)&ThisNetworkInterface->MacAddress, &TargetNetworkInterface->MacAddress, ThisNetworkInterface->HwAddressSize))
>>> +#define VALID_TCP6(TargetNetworkInterface, ThisNetworkInterface) (TargetNetworkInterface->IsIpv6 && (ThisNetworkInterface->NetworkProtocolType == ProtocolTypeTcp6))
>>> +#define VALID_TCP4(TargetNetworkInterface, ThisNetworkInterface) (!TargetNetworkInterface->IsIpv6 && (ThisNetworkInterface->NetworkProtocolType == ProtocolTypeTcp4))
>>> +#define IS_TCP4_MATCH(IpType) ((gRequiredProtocol[Index].ProtocolType == ProtocolTypeTcp4) && (IpType != REDFISH_HOST_INTERFACE_HOST_IP_ADDRESS_FORMAT_IP4))
>>> +#define IS_TCP6_MATCH(IpType) ((gRequiredProtocol[Index].ProtocolType == ProtocolTypeTcp6) && (IpType != REDFISH_HOST_INTERFACE_HOST_IP_ADDRESS_FORMAT_IP6))
>>
>> And these macros to test for ==, not !=
>>
>>
>> Igor: First version tested "==", but we agreed that it may not work if we have a wrong value of IpType.
>>
>> Otherwise the code reads like it does the opposite of what it does.
>>
>> (You could also keep the logic and call the macros IS_TCP#_MISMATCH, but
>> that feels a bit convoluted.)
>>
>> Igor: I would prefer to go with IS_TCP#_MISMATCH names.
>>
>> Regards,
>>
>> Leif
>
> Sorry, could I add my 2 cents?
Always!
> For me all newly added defines looks bad, just because those
> implicitly use reference to a global variable
> plus local variable state (i.e current cycle index).
Fair. But the original test is basically line noise.
I will point out that gRequiredProtocol appears to be misnamed to start
with. It's only used in this file, so ought to be mRequiredProtocol.
However, your point still stands.
> Could we rewrite code in a simple and straight forward manner, similar to:
>
> if (IpType == REDFISH_HOST_INTERFACE_HOST_IP_ADDRESS_FORMAT_UNKNOWN) {
> // The protocol type is not specified in SMBIOS table type 42h
> return EFI_UNSUPPORTED;
> }
The test needs to be an allowlist, not a denylist of specific error
cases. The input is the SMBIOS table, which could have been corrupted
accidentally or intentionally.
But yes, rejecting the outright invalid options upfront is a big
readability improvement.
> for (Index = 0; Index < ListCount; Index++) {
> if ((gRequiredProtocol[Index].ProtocolType == ProtocolTypeTcp4) &&
> (IpType != REDFISH_HOST_INTERFACE_HOST_IP_ADDRESS_FORMAT_IP4)) {
> continue;
> }
> if ((gRequiredProtocol[Index].ProtocolType == ProtocolTypeTcp6) &&
> (IpType != REDFISH_HOST_INTERFACE_HOST_IP_ADDRESS_FORMAT_IP6)) {
> continue;
> }
> <skip>
This still looks somewhat like line noise.
We could stick it in a static helper function to get
BuildupNetworkInterface () more human readable?
Regards,
Leif
> Regards,
> Mike.
>
>
>
>
>
-The information contained in this message may be confidential and proprietary to American Megatrends (AMI). This communication is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited. Please promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and then delete or destroy all copies of the transmission.
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#111277): https://edk2.groups.io/g/devel/message/111277
Mute This Topic: https://groups.io/mt/102584140/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
next prev parent reply other threads:[~2023-11-15 13:52 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 [this message]
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
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=BLAPR10MB5185D5F40E4BEA4D091E6856A8B1A@BLAPR10MB5185.namprd10.prod.outlook.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