On Tuesday, June 11, 2024 11:48 PM, Hannes Reinecke <hare@xxxxxxx> wrote:In generally, adding new functionality to an existing driver is the correct way to do. What I am worrying about is that we avoid code duplication (hence my comment for FIP handling), and that existing
On 6/10/24 23:50, Karan Tilak Kumar wrote:
Add and integrate support for FCoE InitializationAren't you getting a bit overboard here?
(protocol) FIP. This protocol will be exercised on Cisco UCS rack
servers.
Add support to specifically print FIP related debug messages.
Replace existing definitions to handle new data structures.
Clean up old and obsolete definitions.
I am _positive_ that the original fnic driver _did_ do FIP.
What happened to that?
Why can't you just use that implementation?
And if you can't use that implementation, shouldn't this rather be a new driver instead of replacing
most if not all functionality of the original fnic driver?
Thanks for your review comments, Hannes.
As you can see from this patch, and some of the later patches, fnic driver would be reliant on FDLS.
FDLS helps solve some of the issues that we have seen in our hardware where:
1) the adapter hangs such that FC offload is impacted,
2) the fabric gets into a blackhole situation, where nothing comes out of the fabric.
These situations get easily escalated and are quite hard to diagnose.
FDLS has helped us in these instances to chart a way forward, and to solve the issue.
Cisco has been shipping async fnic driver based on FDLS for the past six years.
Cisco officially supports the async driver.
The async driver has support for PC-RSCN (seen in a later patch) and NVME initiators.
Since the async driver has been in the field for quite a while now, it is a well-seasoned driver.
It has also gone through lots of QA cycles to reach a level of stability today.
Therefore, the Cisco team feels comfortable in upstreaming this change.
Keeping in line with the upstreaming best practices, our preferred line of approach is to modify
the existing driver with this change.
I assume that there will be challenges in maintaining two separate upstream drivers and hence the
current approach.
However, we want to be mindful of your comments.
If you believe that a new driver is warranted based on these changes, the Cisco team can evaluate
that approach.
Please share your thoughts with us.