qed, qedi patchset submission

qed, qedi patchset submission

[Arun Easi]

Hi Martin, David,

This is regarding the submission of the recent patch series we have posted
to linux-scsi and netdev:

    [PATCH v2 0/6] Add QLogic FastLinQ iSCSI (qedi) driver.
    [PATCH v2 1/6] qed: Add support for hardware offloaded iSCSI.
    [PATCH v2 2/6] qed: Add iSCSI out of order packet handling.
    [PATCH v2 3/6] qedi: Add QLogic FastLinQ offload iSCSI driver framework.
    [PATCH v2 4/6] qedi: Add LL2 iSCSI interface for offload iSCSI.
    [PATCH v2 5/6] qedi: Add support for iSCSI session management.
    [PATCH v2 6/6] qedi: Add support for data path.

Patches 1 & 2 are "qed" module patches that goes under
drivers/net/ethernet/qlogic/qed/ and include/linux/qed/ directory.
	- These are the iSCSI enablement changes to the common "qed"
	  module. There is no dependency for these patches and so
	  can go independently.

Patches 3, 4, 5 & 6 are the qedi patches that is aimed towards
drivers/scsi/qedi/ directory.
	- These are the core qedi changes and is dependent on the
	  qed changes (invokes qed_XXX functions).

As qed sits in the net tree, the patches are usually submitted via netdev.

Do you have any preference or thoughts on how the "qed" patches be 
approached? Just as a reference, our rdma driver "qedr" went through 
something similar[1], and eventually "qed" patches were taken by David 
in the net tree and "qedr", in the rdma tree (obviously) by Doug L.

Hi David,

For the "qed" enablement sent with the v2 series, we did not prefix the 
qed patches with "[PATCH net-next]" prefix, so netdev folks may have 
failed to notice/review that, sorry about that. We will send the next (v3) 
series with that corrected.

Right now, we are basing the "qed" patches on top of latest net + net-next 
tree. FYI, I tried a test merge of net-next/master + qed patches with 
"net/master" and I see no conflict in qed.

Regards,
-Arun

[1] http://marc.info/?l=linux-rdma&m=147509152719831&w=2

qed, qedi patchset submission

[Arun Easi]

Hi Martin, David,

This is regarding the submission of the recent patch series we have posted
to linux-scsi and netdev:

    [PATCH v2 0/6] Add QLogic FastLinQ iSCSI (qedi) driver.
    [PATCH v2 1/6] qed: Add support for hardware offloaded iSCSI.
    [PATCH v2 2/6] qed: Add iSCSI out of order packet handling.
    [PATCH v2 3/6] qedi: Add QLogic FastLinQ offload iSCSI driver framework.
    [PATCH v2 4/6] qedi: Add LL2 iSCSI interface for offload iSCSI.
    [PATCH v2 5/6] qedi: Add support for iSCSI session management.
    [PATCH v2 6/6] qedi: Add support for data path.

Patches 1 & 2 are "qed" module patches that goes under
drivers/net/ethernet/qlogic/qed/ and include/linux/qed/ directory.
	- These are the iSCSI enablement changes to the common "qed"
	  module. There is no dependency for these patches and so
	  can go independently.

Patches 3, 4, 5 & 6 are the qedi patches that is aimed towards
drivers/scsi/qedi/ directory.
	- These are the core qedi changes and is dependent on the
	  qed changes (invokes qed_XXX functions).

As qed sits in the net tree, the patches are usually submitted via netdev.

Do you have any preference or thoughts on how the "qed" patches be 
approached? Just as a reference, our rdma driver "qedr" went through 
something similar[1], and eventually "qed" patches were taken by David 
in the net tree and "qedr", in the rdma tree (obviously) by Doug L.

Hi David,

For the "qed" enablement sent with the v2 series, we did not prefix the 
qed patches with "[PATCH net-next]" prefix, so netdev folks may have 
failed to notice/review that, sorry about that. We will send the next (v3) 
series with that corrected.

Right now, we are basing the "qed" patches on top of latest net + net-next 
tree. FYI, I tried a test merge of net-next/master + qed patches with 
"net/master" and I see no conflict in qed.

Regards,
-Arun

[1] http://marc.info/?l=linux-rdma&m=147509152719831&w=2

Re: qed, qedi patchset submission

[Martin K. Petersen]

>>>>> "Arun" == Arun Easi <arun.easi@cavium.com> writes:

Arun,

Arun> Do you have any preference or thoughts on how the "qed" patches be
Arun> approached? Just as a reference, our rdma driver "qedr" went
Arun> through something similar[1], and eventually "qed" patches were
Arun> taken by David in the net tree and "qedr", in the rdma tree
Arun> (obviously) by Doug L.

DaveM can queue the whole series or I can hold the SCSI pieces for
rc1. Either way works for me.

However, I would like to do a review of the driver first. I will try to
get it done this week.

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: qed, qedi patchset submission

[Martin K. Petersen]

>>>>> "Arun" == Arun Easi <arun.easi@cavium.com> writes:

Arun,

Arun> Do you have any preference or thoughts on how the "qed" patches be
Arun> approached? Just as a reference, our rdma driver "qedr" went
Arun> through something similar[1], and eventually "qed" patches were
Arun> taken by David in the net tree and "qedr", in the rdma tree
Arun> (obviously) by Doug L.

DaveM can queue the whole series or I can hold the SCSI pieces for
rc1. Either way works for me.

However, I would like to do a review of the driver first. I will try to
get it done this week.

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: qed, qedi patchset submission

[Arun Easi]

Hi David,

As we are preparing to post V3 of the qed (drivers/net/) and qedi 
(drivers/scsi/), I would like to get your opinion on the "qedi" part. As 
qedi (the iSCSI driver) is dependent on the accompanying "qed" changes, 
qedi changes have to follow or be together with qed changes. Martin is ok 
in having you taking the qedi part as well (see below discussion) or wait 
until qed is in, and then take qedi through SCSI tree.

Hi David, Martin,

So far, we have been posting qedi changes split into functional blocks, 
for review, but was not bisectable. With Martin ok to our request to 
squash all patches while committing to tree, we were wondering if we 
should post the qedi patches squashed, with all the Reviewed-by added, or 
continue to post as before?

Regards,
-Arun

On Mon, 14 Nov 2016, 3:47pm, Martin K. Petersen wrote:

> >>>>> "Arun" == Arun Easi <arun.easi@cavium.com> writes:
> 
> Arun,
> 
> Arun> Do you have any preference or thoughts on how the "qed" patches be
> Arun> approached? Just as a reference, our rdma driver "qedr" went
> Arun> through something similar[1], and eventually "qed" patches were
> Arun> taken by David in the net tree and "qedr", in the rdma tree
> Arun> (obviously) by Doug L.
> 
> DaveM can queue the whole series or I can hold the SCSI pieces for
> rc1. Either way works for me.
> 
> However, I would like to do a review of the driver first. I will try to
> get it done this week.
> 
> 

Re: qed, qedi patchset submission

[Arun Easi]

Hi David,

As we are preparing to post V3 of the qed (drivers/net/) and qedi 
(drivers/scsi/), I would like to get your opinion on the "qedi" part. As 
qedi (the iSCSI driver) is dependent on the accompanying "qed" changes, 
qedi changes have to follow or be together with qed changes. Martin is ok 
in having you taking the qedi part as well (see below discussion) or wait 
until qed is in, and then take qedi through SCSI tree.

Hi David, Martin,

So far, we have been posting qedi changes split into functional blocks, 
for review, but was not bisectable. With Martin ok to our request to 
squash all patches while committing to tree, we were wondering if we 
should post the qedi patches squashed, with all the Reviewed-by added, or 
continue to post as before?

Regards,
-Arun

On Mon, 14 Nov 2016, 3:47pm, Martin K. Petersen wrote:

> >>>>> "Arun" == Arun Easi <arun.easi@cavium.com> writes:
> 
> Arun,
> 
> Arun> Do you have any preference or thoughts on how the "qed" patches be
> Arun> approached? Just as a reference, our rdma driver "qedr" went
> Arun> through something similar[1], and eventually "qed" patches were
> Arun> taken by David in the net tree and "qedr", in the rdma tree
> Arun> (obviously) by Doug L.
> 
> DaveM can queue the whole series or I can hold the SCSI pieces for
> rc1. Either way works for me.
> 
> However, I would like to do a review of the driver first. I will try to
> get it done this week.
> 
> 

Re: qed, qedi patchset submission

[Martin K. Petersen]

>>>>> "Arun" == Arun Easi <arun.easi@cavium.com> writes:

Arun,

Arun> So far, we have been posting qedi changes split into functional
Arun> blocks, for review, but was not bisectable. With Martin ok to our
Arun> request to squash all patches while committing to tree, we were
Arun> wondering if we should post the qedi patches squashed, with all
Arun> the Reviewed-by added, or continue to post as before?

I guess it depends how things can be split up in a bisectable fashion.

If the net/ pieces can be completely separated from the scsi/ pieces
maybe it would be best to have two patches?

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: qed, qedi patchset submission

[Martin K. Petersen]

>>>>> "Arun" == Arun Easi <arun.easi@cavium.com> writes:

Arun,

Arun> So far, we have been posting qedi changes split into functional
Arun> blocks, for review, but was not bisectable. With Martin ok to our
Arun> request to squash all patches while committing to tree, we were
Arun> wondering if we should post the qedi patches squashed, with all
Arun> the Reviewed-by added, or continue to post as before?

I guess it depends how things can be split up in a bisectable fashion.

If the net/ pieces can be completely separated from the scsi/ pieces
maybe it would be best to have two patches?

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: qed, qedi patchset submission

[Arun Easi]

Thanks for the response, Martin.

On Wed, 30 Nov 2016, 8:45am, Martin K. Petersen wrote:

> >>>>> "Arun" == Arun Easi <arun.easi@cavium.com> writes:
> 
> Arun,
> 
> Arun> So far, we have been posting qedi changes split into functional
> Arun> blocks, for review, but was not bisectable. With Martin ok to our
> Arun> request to squash all patches while committing to tree, we were
> Arun> wondering if we should post the qedi patches squashed, with all
> Arun> the Reviewed-by added, or continue to post as before?
> 
> I guess it depends how things can be split up in a bisectable fashion.

These were the patches that was sent:
  1 qed: Add support for hardware offloaded iSCSI.
  2 qed: Add iSCSI out of order packet handling.
  3 qedi: Add QLogic FastLinQ offload iSCSI driver framework.
  4 qedi: Add LL2 iSCSI interface for offload iSCSI.
  5 qedi: Add support for iSCSI session management.
  6 qedi: Add support for data path.

> 
> If the net/ pieces can be completely separated from the scsi/ pieces
> maybe it would be best to have two patches?
> 

Yes, those pieces can be completely separated; there are actually 3 parts, 
2 that goes to net/ and 1 to scsi/.

In the list above, 1 & 2 goes to net/ and are bisectable. 3 through 6 are 
scsi/ pieces, which are the ones requested for collapsing.

We will post these pieces for V3, then:

  1 [PATCH v3 net-next 1/3] qed: Add support for hardware offloaded iSCSI.
  2 [PATCH v3 net-next 2/3] qed: Add iSCSI out of order packet handling.
  3 [PATCH v3 3/3] qedi: Add QLogic FastLinQ offload iSCSI driver framework.

Regards,
-Arun

Re: qed, qedi patchset submission

[Arun Easi]

Thanks for the response, Martin.

On Wed, 30 Nov 2016, 8:45am, Martin K. Petersen wrote:

> >>>>> "Arun" == Arun Easi <arun.easi@cavium.com> writes:
> 
> Arun,
> 
> Arun> So far, we have been posting qedi changes split into functional
> Arun> blocks, for review, but was not bisectable. With Martin ok to our
> Arun> request to squash all patches while committing to tree, we were
> Arun> wondering if we should post the qedi patches squashed, with all
> Arun> the Reviewed-by added, or continue to post as before?
> 
> I guess it depends how things can be split up in a bisectable fashion.

These were the patches that was sent:
  1 qed: Add support for hardware offloaded iSCSI.
  2 qed: Add iSCSI out of order packet handling.
  3 qedi: Add QLogic FastLinQ offload iSCSI driver framework.
  4 qedi: Add LL2 iSCSI interface for offload iSCSI.
  5 qedi: Add support for iSCSI session management.
  6 qedi: Add support for data path.

> 
> If the net/ pieces can be completely separated from the scsi/ pieces
> maybe it would be best to have two patches?
> 

Yes, those pieces can be completely separated; there are actually 3 parts, 
2 that goes to net/ and 1 to scsi/.

In the list above, 1 & 2 goes to net/ and are bisectable. 3 through 6 are 
scsi/ pieces, which are the ones requested for collapsing.

We will post these pieces for V3, then:

  1 [PATCH v3 net-next 1/3] qed: Add support for hardware offloaded iSCSI.
  2 [PATCH v3 net-next 2/3] qed: Add iSCSI out of order packet handling.
  3 [PATCH v3 3/3] qedi: Add QLogic FastLinQ offload iSCSI driver framework.

Regards,
-Arun