2269524_en-US

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

2269524_en-US

2269524_en-US

Potential issue of the writeback check condition in Netc_Eth_Ip_SendFrame.

Hello Team,

There may be a potential issue with the writeback check condition in Netc_Eth_Ip_SendFrame for both the S32N55 and S32ZE platforms. 

Since the writeback bit must be cleared by software, it needs to be reset before transmission. If the buffer descriptor (BD) was part of a chain transmitted previously, the writeback bit will not be set, and consequently, BD->bufConfig will not be updated this time because the condition is not met.

Additionally, this condition may cause confusion for customers.

Is my understanding correct, or have I missed anything?

Tangsheng_Zhou_0-1766979729273.png

Thanks!

Best regards,

Tangsheng.


Priority: MEDIUMRTDSource: NXP InternalRe: Potential issue of the writeback check condition in Netc_Eth_Ip_SendFrame.

Hi @Tangsheng_Zhou ,

My understanding is that Tx BD were configured in Eth_Init includes interrupt enable bit and final frame bit enabled. BD exists in 2 formats: normal and writeback. For writeback, this means bit W was set by HW just in case: transmit return errors or extended BD stores timestamp status. Then, in Sendframe function, driver will just handle case writeback, clear this bit and set again bits final, interrupt,... before transmit a new frame. In case, bit W not set, because BD still keep as old, so driver doesn't need to do anything.  So, form my point of view, this is not an issue.

Best regards,

Nhi

Re: Potential issue of the writeback check condition in Netc_Eth_Ip_SendFrame.

While customer send a new frame, the buffconfig or extendBuffconfig depends on an old status in the Tx BD memory, instead of the real customer configuration about extend. It's amazing.

If it's the 1st time to use the Tx BD, who is charge for setting this W bit, and why?


Re: Potential issue of the writeback check condition in Netc_Eth_Ip_SendFrame.

Hi @shuangjunzhu ,

Sorry, I don't understand your opinion. Can you please explain it in detail about what issue made you concern?

As I said before, TX BD were initialized first at Eth_Init() in the function Netc_Eth_Ip_InitTxBD(). bit W will be cleared here for first time.

Tx BD will be kept until errors were detected, then error flags were raised with bit W raised to indicate status. Or timestamp are in extended BD. For this case, driver will set up again Tx BD in the function SendFrame.

If bit W not set, TxBD not change, they were kept as in the first configuration why driver has to configure them in SendFrame?

Best regards,

Nhi


Re: Potential issue of the writeback check condition in Netc_Eth_Ip_SendFrame.

1. Since the Tx BD buffconfig W bit is a response of previous frame from NETC, the device driver should handle this W bit in Netc_Eth_Ip_CheckFrameStatus(), if you would like to keep the Tx BD to default config status likeTX BD were initialized first at Eth_Init(). Is it correct?

2. In Netc_Eth_Ip_SendFrame(), the device driver assume all the Tx BDs will use the default buffConfig and extendBuffConfig in the memory, and assume there is nobody will change the memory. If previous frame has an option like "TimestampRefReq", but current frame has no this option, who will remove it?

3. What's the purpose of this piece of code? for performance to save several cycles? for better read-able? It does not make sense for me. If we want to save cycles, how about this line of code "txBD->RESERVED_0 = (uint32)0U", we might remove it as well.


Re: Potential issue of the writeback check condition in Netc_Eth_Ip_SendFrame.

Hi 

Thanks for your kindly answer. But still have question, actually, the "TimestampRefReq" just an example.

Are you sure, for all the management frames, there will be a W bit set by NETC as the response? Or similar, the NETC_ETH_IP_TXSTART option will cause a W bit response as well?

Re: Potential issue of the writeback check condition in Netc_Eth_Ip_SendFrame.

Hi @shuangjunzhu ,

From my point of view, all of other options are always request a response, so bit W should be set. We haven't see any problem until now although I think that set up Des2 of BD in sendframe() is ok even bit W not set, as you mentioned that it shouldn't be problem to save performance with this but still need the reason for changing code. So, please let me know if you detect the problem.

Best regards,

Nhi

Re: Potential issue of the writeback check condition in Netc_Eth_Ip_SendFrame.

Hi @shuangjunzhu ,

I understand that TxBD will be configured in the function SendFrame() includes fields as its structure before transmitting a frame.

Nhi_Nguyen_0-1767770318784.png

Nhi_Nguyen_1-1767770590416.png

except Des2 that contains bit F, W.

Des2 will be in 2 cases:

1 - normal BD that bit W not set.

2 - writeback BD that bit W set. 

As RM mentioned that bit W just set in case requested offload or error.

Nhi_Nguyen_2-1767770869119.png

So, in case bit W not set, TX BD not change.

1. Set fields of Tx BD were done in the function SendFrame(), so in the function CheckFrameStatus(), driver just returns errors, status, not configure BD .

2. If previous frame has TimestampRefReq = 1, then BD status will returns with bit W set. So, that BD will be configured Des 2(F + W) in the function SendFrame() although current frame without TimestampRefReq . For example:

This is TxBD after configured in SendFrame():

Nhi_Nguyen_3-1767771585076.png

After sending frame, BD returns status:

Nhi_Nguyen_4-1767771638122.png

3. I mentioned this above.

Best regards,

Nhi


Re: Potential issue of the writeback check condition in Netc_Eth_Ip_SendFrame.

Hi @shuangjunzhu ,

This is case NETC_ETH_IP_TXSTART, I saw bit W still set.

Nhi_Nguyen_0-1767841604920.png

Nhi_Nguyen_1-1767841622063.png


Best regards,

Nhi

Re: Potential issue of the writeback check condition in Netc_Eth_Ip_SendFrame.

Hi Nhi_Nguyen,

We did the experiment, if previous frame has the option NETC_ETH_IP_TXSTART. There will be NO W bit response from NETC hardware. The current frame with this Tx BD will has the "dirty" option NETC_ETH_IP_TXSTART from previous transmission action.

It does not make sense.

Please help to review.

Thanks,

Re: Potential issue of the writeback check condition in Netc_Eth_Ip_SendFrame.

Hi,


According to your capture, something wrong with the status 0x60 and W bit is set. So the W bit is for error response, not for NETC_ETH_IP_TXSTART.

Thanks,


Re: Potential issue of the writeback check condition in Netc_Eth_Ip_SendFrame.

Hi @shuangjunzhu ,

Yes, you're right. Bit W was set because error reported. I tested again and I agree that Des2 in Tx BD should be configured even bit W not set in the function SendFrame().

Nhi_Nguyen_0-1767950627218.png

Nhi_Nguyen_1-1767950643094.png

I created the ticket ARTDCC1-583 for this.

Thanks & Best regards,

Nhi


タグ(1)
評価なし
バージョン履歴
最終更新日:
‎01-10-2026 02:17 AM
更新者: