On 9/20/23 17:04, Jacob Keller wrote:
>
>
> On 9/20/2023 2:30 PM, Randy Dunlap wrote:
>>
>>
>> On 9/20/23 11:07, Alexander Lobakin wrote:
>>> When CONFIG_INET is not set, tcp_gro_complete is not compiled, although
>>> the drivers using it may still be compiled (spotted by Randy):
>>>
>>> aarch64-linux-ld: drivers/net/ethernet/intel/idpf/idpf_txrx.o:
>>> in function `idpf_rx_rsc.isra.0':
>>> drivers/net/ethernet/intel/idpf/idpf_txrx.c:2909:(.text+0x40cc):
>>> undefined reference to `tcp_gro_complete'
>>>
>>> The drivers need to guard the calls to it manually.
>>> Return early from the RSC completion function if !CONFIG_INET, it won't
>>> work properly either way. This effectively makes it be compiled-out
>>> almost entirely on such builds.
>>>
>>> Fixes: 3a8845af66ed ("idpf: add RX splitq napi poll support")
>>> Reported-by: Randy Dunlap <[email protected]>
>>> Closes: https://lore.kernel.org/linux-next/[email protected]
>>> Signed-off-by: Alexander Lobakin <[email protected]>
>>
>> That builds for me. Thanks.
>>
>> Tested-by: Randy Dunlap <[email protected]>
>>
>> I hope that these patches can be merged into the v6.6 instead of
>> v6.7 kernel at some point (i.e., [PATCH net] instead of net-next).
>>
>
> Did any of the offending code make it into 6.6? I thought all of this
> was from recent merges after 6.6 closed.
>
> Thanks,
> Jake
Oh, I think that you are correct. Sorry about my comment.
Thanks.
>
>>
>>> ---
>>> drivers/net/ethernet/intel/idpf/idpf_txrx.c | 3 +++
>>> 1 file changed, 3 insertions(+)
>>>
>>> diff --git a/drivers/net/ethernet/intel/idpf/idpf_txrx.c b/drivers/net/ethernet/intel/idpf/idpf_txrx.c
>>> index 6fa79898c42c..aa45afeb6496 100644
>>> --- a/drivers/net/ethernet/intel/idpf/idpf_txrx.c
>>> +++ b/drivers/net/ethernet/intel/idpf/idpf_txrx.c
>>> @@ -2876,6 +2876,9 @@ static int idpf_rx_rsc(struct idpf_queue *rxq, struct sk_buff *skb,
>>> if (unlikely(!(ipv4 ^ ipv6)))
>>> return -EINVAL;
>>>
>>> + if (!IS_ENABLED(CONFIG_INET))
>>> + return 0;
>>> +
>>> rsc_segments = DIV_ROUND_UP(skb->data_len, rsc_seg_len);
>>> if (unlikely(rsc_segments == 1))
>>> return 0;
>>
--
~Randy
Hi,
On 9/20/23 18:30, Randy Dunlap wrote:
>
>
> On 9/20/23 17:04, Jacob Keller wrote:
>>
>>
>> On 9/20/2023 2:30 PM, Randy Dunlap wrote:
>>>
>>>
>>> On 9/20/23 11:07, Alexander Lobakin wrote:
>>>> When CONFIG_INET is not set, tcp_gro_complete is not compiled, although
>>>> the drivers using it may still be compiled (spotted by Randy):
>>>>
>>>> aarch64-linux-ld: drivers/net/ethernet/intel/idpf/idpf_txrx.o:
>>>> in function `idpf_rx_rsc.isra.0':
>>>> drivers/net/ethernet/intel/idpf/idpf_txrx.c:2909:(.text+0x40cc):
>>>> undefined reference to `tcp_gro_complete'
>>>>
>>>> The drivers need to guard the calls to it manually.
>>>> Return early from the RSC completion function if !CONFIG_INET, it won't
>>>> work properly either way. This effectively makes it be compiled-out
>>>> almost entirely on such builds.
>>>>
>>>> Fixes: 3a8845af66ed ("idpf: add RX splitq napi poll support")
>>>> Reported-by: Randy Dunlap <[email protected]>
>>>> Closes: https://lore.kernel.org/linux-next/[email protected]
>>>> Signed-off-by: Alexander Lobakin <[email protected]>
>>>
>>> That builds for me. Thanks.
>>>
>>> Tested-by: Randy Dunlap <[email protected]>
>>>
>>> I hope that these patches can be merged into the v6.6 instead of
>>> v6.7 kernel at some point (i.e., [PATCH net] instead of net-next).
>>>
>>
>> Did any of the offending code make it into 6.6? I thought all of this
>> was from recent merges after 6.6 closed.
>>
>> Thanks,
>> Jake
>
> Oh, I think that you are correct. Sorry about my comment.
> Thanks.
>
Even if this is just > v6.6 kernels (i.e., linux-next),
it would be very good to get a fix merged for these build errors.
I keep getting build errors in linux-next....
>>
>>>
>>>> ---
>>>> drivers/net/ethernet/intel/idpf/idpf_txrx.c | 3 +++
>>>> 1 file changed, 3 insertions(+)
>>>>
>>>> diff --git a/drivers/net/ethernet/intel/idpf/idpf_txrx.c b/drivers/net/ethernet/intel/idpf/idpf_txrx.c
>>>> index 6fa79898c42c..aa45afeb6496 100644
>>>> --- a/drivers/net/ethernet/intel/idpf/idpf_txrx.c
>>>> +++ b/drivers/net/ethernet/intel/idpf/idpf_txrx.c
>>>> @@ -2876,6 +2876,9 @@ static int idpf_rx_rsc(struct idpf_queue *rxq, struct sk_buff *skb,
>>>> if (unlikely(!(ipv4 ^ ipv6)))
>>>> return -EINVAL;
>>>>
>>>> + if (!IS_ENABLED(CONFIG_INET))
>>>> + return 0;
>>>> +
>>>> rsc_segments = DIV_ROUND_UP(skb->data_len, rsc_seg_len);
>>>> if (unlikely(rsc_segments == 1))
>>>> return 0;
>>>
>
Thanks.
--
~Randy
From: Randy Dunlap <[email protected]>
Date: Thu, 12 Oct 2023 08:47:12 -0700
> Hi,
>
> On 9/20/23 18:30, Randy Dunlap wrote:
>>
>>
>> On 9/20/23 17:04, Jacob Keller wrote:
>>>
>>>
>>> On 9/20/2023 2:30 PM, Randy Dunlap wrote:
>>>>
>>>>
>>>> On 9/20/23 11:07, Alexander Lobakin wrote:
>>>>> When CONFIG_INET is not set, tcp_gro_complete is not compiled, although
>>>>> the drivers using it may still be compiled (spotted by Randy):
>>>>>
>>>>> aarch64-linux-ld: drivers/net/ethernet/intel/idpf/idpf_txrx.o:
>>>>> in function `idpf_rx_rsc.isra.0':
>>>>> drivers/net/ethernet/intel/idpf/idpf_txrx.c:2909:(.text+0x40cc):
>>>>> undefined reference to `tcp_gro_complete'
>>>>>
>>>>> The drivers need to guard the calls to it manually.
>>>>> Return early from the RSC completion function if !CONFIG_INET, it won't
>>>>> work properly either way. This effectively makes it be compiled-out
>>>>> almost entirely on such builds.
>>>>>
>>>>> Fixes: 3a8845af66ed ("idpf: add RX splitq napi poll support")
>>>>> Reported-by: Randy Dunlap <[email protected]>
>>>>> Closes: https://lore.kernel.org/linux-next/[email protected]
>>>>> Signed-off-by: Alexander Lobakin <[email protected]>
>>>>
>>>> That builds for me. Thanks.
>>>>
>>>> Tested-by: Randy Dunlap <[email protected]>
>>>>
>>>> I hope that these patches can be merged into the v6.6 instead of
>>>> v6.7 kernel at some point (i.e., [PATCH net] instead of net-next).
>>>>
>>>
>>> Did any of the offending code make it into 6.6? I thought all of this
>>> was from recent merges after 6.6 closed.
>>>
>>> Thanks,
>>> Jake
>>
>> Oh, I think that you are correct. Sorry about my comment.
>> Thanks.
>>
>
> Even if this is just > v6.6 kernels (i.e., linux-next),
> it would be very good to get a fix merged for these build errors.
> I keep getting build errors in linux-next....
I don't know what happened, Tony dropped this commit from his tree due
to that we agreed yours (which optimizes out IPv6 code if it's not
enabled) is better, then Tony asked the netdev maintainers whether it
can be taken directly, but no updates since then.
I also asked Tony why he took my patch into his tree while I wrote under
the commit message that it should've been taken directly, also no replies :D
And all that for the bug that breaks linux-next build, meh.
>
>>>
>>>>
>>>>> ---
>>>>> drivers/net/ethernet/intel/idpf/idpf_txrx.c | 3 +++
>>>>> 1 file changed, 3 insertions(+)
>>>>>
>>>>> diff --git a/drivers/net/ethernet/intel/idpf/idpf_txrx.c b/drivers/net/ethernet/intel/idpf/idpf_txrx.c
>>>>> index 6fa79898c42c..aa45afeb6496 100644
>>>>> --- a/drivers/net/ethernet/intel/idpf/idpf_txrx.c
>>>>> +++ b/drivers/net/ethernet/intel/idpf/idpf_txrx.c
>>>>> @@ -2876,6 +2876,9 @@ static int idpf_rx_rsc(struct idpf_queue *rxq, struct sk_buff *skb,
>>>>> if (unlikely(!(ipv4 ^ ipv6)))
>>>>> return -EINVAL;
>>>>>
>>>>> + if (!IS_ENABLED(CONFIG_INET))
>>>>> + return 0;
>>>>> +
>>>>> rsc_segments = DIV_ROUND_UP(skb->data_len, rsc_seg_len);
>>>>> if (unlikely(rsc_segments == 1))
>>>>> return 0;
>>>>
>>
>
> Thanks.
Thanks,
Olek
> -----Original Message-----
> From: Randy Dunlap <[email protected]>
> Sent: Thursday, October 12, 2023 8:47 AM
> To: Keller, Jacob E <[email protected]>; Lobakin, Aleksander
> <[email protected]>; David S. Miller <[email protected]>; Eric
> Dumazet <[email protected]>; Jakub Kicinski <[email protected]>; Paolo
> Abeni <[email protected]>
> Cc: Michalik, Michal <[email protected]>; [email protected];
> Richard Cochran <[email protected]>; [email protected];
> Kubalewski, Arkadiusz <[email protected]>; intel-wired-
> [email protected]; Nguyen, Anthony L <[email protected]>; Olech,
> Milena <[email protected]>
> Subject: Re: [Intel-wired-lan] [PATCH net-next 3/3] idpf: fix undefined reference to
> tcp_gro_complete() when !CONFIG_INET
>
> Hi,
>
> On 9/20/23 18:30, Randy Dunlap wrote:
> >
> >
> > On 9/20/23 17:04, Jacob Keller wrote:
> >>
> >>
> >> On 9/20/2023 2:30 PM, Randy Dunlap wrote:
> >>>
> >>>
> >>> On 9/20/23 11:07, Alexander Lobakin wrote:
> >>>> When CONFIG_INET is not set, tcp_gro_complete is not compiled, although
> >>>> the drivers using it may still be compiled (spotted by Randy):
> >>>>
> >>>> aarch64-linux-ld: drivers/net/ethernet/intel/idpf/idpf_txrx.o:
> >>>> in function `idpf_rx_rsc.isra.0':
> >>>> drivers/net/ethernet/intel/idpf/idpf_txrx.c:2909:(.text+0x40cc):
> >>>> undefined reference to `tcp_gro_complete'
> >>>>
> >>>> The drivers need to guard the calls to it manually.
> >>>> Return early from the RSC completion function if !CONFIG_INET, it won't
> >>>> work properly either way. This effectively makes it be compiled-out
> >>>> almost entirely on such builds.
> >>>>
> >>>> Fixes: 3a8845af66ed ("idpf: add RX splitq napi poll support")
> >>>> Reported-by: Randy Dunlap <[email protected]>
> >>>> Closes: https://lore.kernel.org/linux-next/4c84eb7b-3dec-467b-934b-
> [email protected]
> >>>> Signed-off-by: Alexander Lobakin <[email protected]>
> >>>
> >>> That builds for me. Thanks.
> >>>
> >>> Tested-by: Randy Dunlap <[email protected]>
> >>>
> >>> I hope that these patches can be merged into the v6.6 instead of
> >>> v6.7 kernel at some point (i.e., [PATCH net] instead of net-next).
> >>>
> >>
> >> Did any of the offending code make it into 6.6? I thought all of this
> >> was from recent merges after 6.6 closed.
> >>
> >> Thanks,
> >> Jake
> >
> > Oh, I think that you are correct. Sorry about my comment.
> > Thanks.
> >
>
> Even if this is just > v6.6 kernels (i.e., linux-next),
> it would be very good to get a fix merged for these build errors.
> I keep getting build errors in linux-next....
>
A standalone version for the idpf driver fix was posted at [1], and another alternative fix was posted at [2]
Fixes for the ice driver have already merged.
[1]: https://lore.kernel.org/netdev/[email protected]/
[2]: https://lore.kernel.org/netdev/[email protected]/
The fix from Arnd got approval from Olek, but it seems like it stalled out after asking about stubs. I'm fine with either approach but would also like to see a fix merge soon.
Thanks,
Jake
On Thu, 12 Oct 2023 18:34:00 +0000 Keller, Jacob E wrote:
> > Even if this is just > v6.6 kernels (i.e., linux-next),
> > it would be very good to get a fix merged for these build errors.
> > I keep getting build errors in linux-next....
>
> A standalone version for the idpf driver fix was posted at [1], and
> another alternative fix was posted at [2]
>
> Fixes for the ice driver have already merged.
>
> [1]:
> https://lore.kernel.org/netdev/[email protected]/
> [2]:
> https://lore.kernel.org/netdev/[email protected]/
>
> The fix from Arnd got approval from Olek, but it seems like it
> stalled out after asking about stubs. I'm fine with either approach
> but would also like to see a fix merge soon.
The suggestion of making NET == INET is quite tempting but requires
extra consideration. Since nobody seems to have the cycles, let's
go with the stubs?
On 10/12/2023 4:31 PM, Jakub Kicinski wrote:
> On Thu, 12 Oct 2023 18:34:00 +0000 Keller, Jacob E wrote:
>>> Even if this is just > v6.6 kernels (i.e., linux-next),
>>> it would be very good to get a fix merged for these build errors.
>>> I keep getting build errors in linux-next....
>>
>> A standalone version for the idpf driver fix was posted at [1], and
>> another alternative fix was posted at [2]
>>
>> Fixes for the ice driver have already merged.
>>
>> [1]:
>> https://lore.kernel.org/netdev/[email protected]/
>> [2]:
>> https://lore.kernel.org/netdev/[email protected]/
>>
>> The fix from Arnd got approval from Olek, but it seems like it
>> stalled out after asking about stubs. I'm fine with either approach
>> but would also like to see a fix merge soon.
>
> The suggestion of making NET == INET is quite tempting but requires
> extra consideration. Since nobody seems to have the cycles, let's
> go with the stubs?
>
Yea. I think NET == INET would cause a bit more challenge in the
immediate term. Its possibly worth exploring but it would be nice to get
the build bots happy first.
I can take the time this morning to work on a version that implements
the stub, and post it.
Thanks,
Jake