[dpdk-dev] [PATCH 0/3] null driver improvements for testability
On 23/02/16 15:21, Bruce Richardson wrote: > On Thu, Feb 18, 2016 at 12:19:58PM +, Paul Atkins wrote: >> >> On 17/02/16 17:23, Bruce Richardson wrote: >>> On Fri, Jan 29, 2016 at 04:47:58PM +, Paul Atkins wrote: Hi Thomas, On 29/01/16 16:31, Thomas Monjalon wrote: > Hi Paul, > > 2016-01-29 16:18, Paul Atkins: >> This patchset adds functionality to the null driver help when testing >> a dataplane that uses dpdk. The idea is that the the dataplane can >> have multiple null interfaces attached, and each of theses can be >> assigned a mac address. Packets can then be injected into the null >> drivers by adding them to a ring, giving the application complete >> control of the packets that arrive. Packets that are sent by a null >> driver can be stored on a ring, where the application can pick them up >> and verify it is what was expected. To allow the application to know >> when packets have been pulled of the rx ring, counters of the number of >> times an rx poll has been made are kept, and these can be retrieved via >> the existing APIs. > I have not read your code, just read this description. > It sounds like being a ring PMD. Have you already checked it? > https://urldefense.proofpoint.com/v2/url?u=http-3A__dpdk.org_browse_dpdk_tree_drivers_net_ring_rte-5Feth-5Fring.c=CwICAg=IL_XqQWOjubgfqINi2jTzg=45ezphVDEm8OnEpH-fLWdXvR3RneLhhNZRDLQRgR6LY=wJLO24XFe_B0nZve6mkvocCt7fQWo3PULCTWxrC8rZk=bIWycJrY-PYgzkQsBeRfkl8JCHFcxRAHhHDrqRSzHYs= I hadn't seen the ring PMD. I will have a look at it and see if I can make it do what i need. thanks, Paul >>> Hi Paul, >>> >>> any update on this. Your patches are still showing as pending in patchwork, >>> but >>> if ring pmd is more what need, we can set these patches aside as unneeded, >>> and >>> remove them from the patchwork merge backlog. >> Hi Bruce, >> >> Sorry for the delay. The patchset adds 3 things: assigning a mac addr to >> the null pmd, adding the rings to the null pmd and adding xstats for how >> many times the null pmd has been polled. I could move to using the ring >> pmd, but I would still need the other 2 parts (mac addr and stats). It >> seems like the ring pmd shouldn't really have these two extra things added, >> but i could do that if it that is preferred over what is in the current >> patchset. >> > Adding a mac address to be reported by the ring PMD should not be a problem. > Having a stat that tracks polls might be depending on how it is done - if it > uses an atomic, as in this patchset, it would problematic as it would add a > severe performance hit for the SP/SC ring case. However, you could get around > that by copying what is already done in the PMD for tracking packet counts. > > Overall, though, it seems that it might be worthwhile doing the work to extend > the ring pmd rather than turning the null pmd into a second ring one. Ok, I will make those changes and resubmit - you can mark the current patches as unneeded. thanks, Paul > > Regards, > /Bruce
[dpdk-dev] [PATCH 0/3] null driver improvements for testability
On Thu, Feb 18, 2016 at 12:19:58PM +, Paul Atkins wrote: > > > On 17/02/16 17:23, Bruce Richardson wrote: > >On Fri, Jan 29, 2016 at 04:47:58PM +, Paul Atkins wrote: > >>Hi Thomas, > >> > >>On 29/01/16 16:31, Thomas Monjalon wrote: > >>>Hi Paul, > >>> > >>>2016-01-29 16:18, Paul Atkins: > This patchset adds functionality to the null driver help when testing > a dataplane that uses dpdk. The idea is that the the dataplane can > have multiple null interfaces attached, and each of theses can be > assigned a mac address. Packets can then be injected into the null > drivers by adding them to a ring, giving the application complete > control of the packets that arrive. Packets that are sent by a null > driver can be stored on a ring, where the application can pick them up > and verify it is what was expected. To allow the application to know > when packets have been pulled of the rx ring, counters of the number of > times an rx poll has been made are kept, and these can be retrieved via > the existing APIs. > >>>I have not read your code, just read this description. > >>>It sounds like being a ring PMD. Have you already checked it? > >>>https://urldefense.proofpoint.com/v2/url?u=http-3A__dpdk.org_browse_dpdk_tree_drivers_net_ring_rte-5Feth-5Fring.c=CwICAg=IL_XqQWOjubgfqINi2jTzg=45ezphVDEm8OnEpH-fLWdXvR3RneLhhNZRDLQRgR6LY=wJLO24XFe_B0nZve6mkvocCt7fQWo3PULCTWxrC8rZk=bIWycJrY-PYgzkQsBeRfkl8JCHFcxRAHhHDrqRSzHYs= > >>I hadn't seen the ring PMD. I will have a look at it and see if I can make > >>it do what i need. > >> > >>thanks, > >>Paul > >Hi Paul, > > > >any update on this. Your patches are still showing as pending in patchwork, > >but > >if ring pmd is more what need, we can set these patches aside as unneeded, > >and > >remove them from the patchwork merge backlog. > > Hi Bruce, > > Sorry for the delay. The patchset adds 3 things: assigning a mac addr to > the null pmd, adding the rings to the null pmd and adding xstats for how > many times the null pmd has been polled. I could move to using the ring > pmd, but I would still need the other 2 parts (mac addr and stats). It > seems like the ring pmd shouldn't really have these two extra things added, > but i could do that if it that is preferred over what is in the current > patchset. > Adding a mac address to be reported by the ring PMD should not be a problem. Having a stat that tracks polls might be depending on how it is done - if it uses an atomic, as in this patchset, it would problematic as it would add a severe performance hit for the SP/SC ring case. However, you could get around that by copying what is already done in the PMD for tracking packet counts. Overall, though, it seems that it might be worthwhile doing the work to extend the ring pmd rather than turning the null pmd into a second ring one. Regards, /Bruce
[dpdk-dev] [PATCH 0/3] null driver improvements for testability
On 17/02/16 17:23, Bruce Richardson wrote: > On Fri, Jan 29, 2016 at 04:47:58PM +, Paul Atkins wrote: >> Hi Thomas, >> >> On 29/01/16 16:31, Thomas Monjalon wrote: >>> Hi Paul, >>> >>> 2016-01-29 16:18, Paul Atkins: This patchset adds functionality to the null driver help when testing a dataplane that uses dpdk. The idea is that the the dataplane can have multiple null interfaces attached, and each of theses can be assigned a mac address. Packets can then be injected into the null drivers by adding them to a ring, giving the application complete control of the packets that arrive. Packets that are sent by a null driver can be stored on a ring, where the application can pick them up and verify it is what was expected. To allow the application to know when packets have been pulled of the rx ring, counters of the number of times an rx poll has been made are kept, and these can be retrieved via the existing APIs. >>> I have not read your code, just read this description. >>> It sounds like being a ring PMD. Have you already checked it? >>> https://urldefense.proofpoint.com/v2/url?u=http-3A__dpdk.org_browse_dpdk_tree_drivers_net_ring_rte-5Feth-5Fring.c=CwICAg=IL_XqQWOjubgfqINi2jTzg=45ezphVDEm8OnEpH-fLWdXvR3RneLhhNZRDLQRgR6LY=wJLO24XFe_B0nZve6mkvocCt7fQWo3PULCTWxrC8rZk=bIWycJrY-PYgzkQsBeRfkl8JCHFcxRAHhHDrqRSzHYs= >> I hadn't seen the ring PMD. I will have a look at it and see if I can make >> it do what i need. >> >> thanks, >> Paul > Hi Paul, > > any update on this. Your patches are still showing as pending in patchwork, > but > if ring pmd is more what need, we can set these patches aside as unneeded, and > remove them from the patchwork merge backlog. Hi Bruce, Sorry for the delay. The patchset adds 3 things: assigning a mac addr to the null pmd, adding the rings to the null pmd and adding xstats for how many times the null pmd has been polled. I could move to using the ring pmd, but I would still need the other 2 parts (mac addr and stats). It seems like the ring pmd shouldn't really have these two extra things added, but i could do that if it that is preferred over what is in the current patchset. thanks, Paul > > thanks, > /Bruce
[dpdk-dev] [PATCH 0/3] null driver improvements for testability
On Fri, Jan 29, 2016 at 04:47:58PM +, Paul Atkins wrote: > Hi Thomas, > > On 29/01/16 16:31, Thomas Monjalon wrote: > >Hi Paul, > > > >2016-01-29 16:18, Paul Atkins: > >>This patchset adds functionality to the null driver help when testing > >>a dataplane that uses dpdk. The idea is that the the dataplane can > >>have multiple null interfaces attached, and each of theses can be > >>assigned a mac address. Packets can then be injected into the null > >>drivers by adding them to a ring, giving the application complete > >>control of the packets that arrive. Packets that are sent by a null > >>driver can be stored on a ring, where the application can pick them up > >>and verify it is what was expected. To allow the application to know > >>when packets have been pulled of the rx ring, counters of the number of > >>times an rx poll has been made are kept, and these can be retrieved via > >>the existing APIs. > >I have not read your code, just read this description. > >It sounds like being a ring PMD. Have you already checked it? > >https://urldefense.proofpoint.com/v2/url?u=http-3A__dpdk.org_browse_dpdk_tree_drivers_net_ring_rte-5Feth-5Fring.c=CwICAg=IL_XqQWOjubgfqINi2jTzg=45ezphVDEm8OnEpH-fLWdXvR3RneLhhNZRDLQRgR6LY=wJLO24XFe_B0nZve6mkvocCt7fQWo3PULCTWxrC8rZk=bIWycJrY-PYgzkQsBeRfkl8JCHFcxRAHhHDrqRSzHYs= > > I hadn't seen the ring PMD. I will have a look at it and see if I can make > it do what i need. > > thanks, > Paul Hi Paul, any update on this. Your patches are still showing as pending in patchwork, but if ring pmd is more what need, we can set these patches aside as unneeded, and remove them from the patchwork merge backlog. thanks, /Bruce
[dpdk-dev] [PATCH 0/3] null driver improvements for testability
Hi Paul, 2016-01-29 16:18, Paul Atkins: > This patchset adds functionality to the null driver help when testing > a dataplane that uses dpdk. The idea is that the the dataplane can > have multiple null interfaces attached, and each of theses can be > assigned a mac address. Packets can then be injected into the null > drivers by adding them to a ring, giving the application complete > control of the packets that arrive. Packets that are sent by a null > driver can be stored on a ring, where the application can pick them up > and verify it is what was expected. To allow the application to know > when packets have been pulled of the rx ring, counters of the number of > times an rx poll has been made are kept, and these can be retrieved via > the existing APIs. I have not read your code, just read this description. It sounds like being a ring PMD. Have you already checked it? http://dpdk.org/browse/dpdk/tree/drivers/net/ring/rte_eth_ring.c
[dpdk-dev] [PATCH 0/3] null driver improvements for testability
Hi Thomas, On 29/01/16 16:31, Thomas Monjalon wrote: > Hi Paul, > > 2016-01-29 16:18, Paul Atkins: >> This patchset adds functionality to the null driver help when testing >> a dataplane that uses dpdk. The idea is that the the dataplane can >> have multiple null interfaces attached, and each of theses can be >> assigned a mac address. Packets can then be injected into the null >> drivers by adding them to a ring, giving the application complete >> control of the packets that arrive. Packets that are sent by a null >> driver can be stored on a ring, where the application can pick them up >> and verify it is what was expected. To allow the application to know >> when packets have been pulled of the rx ring, counters of the number of >> times an rx poll has been made are kept, and these can be retrieved via >> the existing APIs. > I have not read your code, just read this description. > It sounds like being a ring PMD. Have you already checked it? > https://urldefense.proofpoint.com/v2/url?u=http-3A__dpdk.org_browse_dpdk_tree_drivers_net_ring_rte-5Feth-5Fring.c=CwICAg=IL_XqQWOjubgfqINi2jTzg=45ezphVDEm8OnEpH-fLWdXvR3RneLhhNZRDLQRgR6LY=wJLO24XFe_B0nZve6mkvocCt7fQWo3PULCTWxrC8rZk=bIWycJrY-PYgzkQsBeRfkl8JCHFcxRAHhHDrqRSzHYs= I hadn't seen the ring PMD. I will have a look at it and see if I can make it do what i need. thanks, Paul
[dpdk-dev] [PATCH 0/3] null driver improvements for testability
This patchset adds functionality to the null driver help when testing a dataplane that uses dpdk. The idea is that the the dataplane can have multiple null interfaces attached, and each of theses can be assigned a mac address. Packets can then be injected into the null drivers by adding them to a ring, giving the application complete control of the packets that arrive. Packets that are sent by a null driver can be stored on a ring, where the application can pick them up and verify it is what was expected. To allow the application to know when packets have been pulled of the rx ring, counters of the number of times an rx poll has been made are kept, and these can be retrieved via the existing APIs. All of these enhancements are using the existing APIs, and do not modify the existing behaviour of the null driver if these features are not configured. Paul Atkins (3): null: add a new arg to allow users to specify ether address null: add rings to allow user to provide the mbufs for rx/tx null: add xstats to provide the number of rx polls drivers/net/null/rte_eth_null.c | 214 +-- 1 file changed, 203 insertions(+), 11 deletions(-) -- 1.7.10.4
